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In thi^ Issue 

The phenomenal growth anrf complexity of cempiJler networks has created s 
wealth of opportunities for communication and resource sharing and a multitude 
of concerns about privacy and security. The Open Software Foundation's Distrib- 
uted Computing Environment IDCEI was developed to fill the need for b stan- 
dardized approach to creating and executing secure client/server applications 
in complex, highly networked environments. Applications developed using the 
DCE software system are portahie and interoperable over a wide range of com- 
puters and networks. AppltcatEons running in DCE are also able to share data 
and services efficiently and securely regardless of the number of computers 
used or where they are located. HR like some other companies in the computer 
industry, has contributed technologies to DCE and released several versions of DCE as a product for the 
HP-UX* operating system, The first eight articles in this issue describe the fundamental elements of 
DCE and the enhancements made to DCE by HP in the areas of application development and security. 

DCE is based on the client/server model in which an application's functionality is divided between cli- 
ents, which represent users, and servers, which provide the services requested by users. In a DCE envi- 
ronment, there might be several thousand host systems, some of which might be from different vendors, 
and many different categories of users and applications. To deal with this heterogeneous and diverse 
environment, DCE defines a basic unit of operation and administration called a cell, which allows users, 
systems, and resources to be grouped together according to their needs and common interests. The 
client^server paradigm and the concept of cells are introduced in the article on page 6. This article also 
introduces features in DCE that facilitate concurrent programming, DCE client/server remote communi- 
cation, time synchronization between distritayted hosts, and handling a distributed file system. 

Encouraging others to adopt a new technology is made a lot easier if you have examples of its use. HP's 
information technology group has adopted DCE and has begun to move HP's legacy information technol- 
ogy system to the DCE architecture. The article on page 16 describes the issues and rationale that led 
HP to adopt DCE for information technology, and the administration and planning issues associated with 
this transition. 

Atypical DCE cell can span several systems and networks. To find users, files, devices, and resources 
inside and outside these cells requires a naming system that allows each cell and the objects contained 
inside it to have unique names, and a directory service that can cope with different naming systems. The 
article on page 23 describes the DCE directory services and the article on page 28 describes the X/Open' 
Federated Naming specification, which defines a uniform naming interface for accessing a variety of 
naming systems. 

One of the biggest issues surrounding networked systems today is security. How do we protect an 
open, distributed system from unauthorized access and abuse? DCE provides a collection of services 
for developing security mechanisms to protect against unauthorized access. The user's password is the 
primary key for getting into a system, and in some situations users may be required to enter several 
passwords during a session to gain access to different applications or other parts of the system. Each 
time the user is required to enter another password, the system is made vufnerable to an opportunity for 
hostile invasion. The article on page 34 describes the HP Integrated Login product, which (s a single-step 
login facility in which the user enters a password once at login time, and this password is used to grant 
access to the HP-UX machine as well to verify access to other secured parts of the system. The security 
protocol that takes over after the password is entered is described in the DCE security service article on 
page 4T The DCE security service authenticates a legitimate user and then checks to make sure that the 
user is authorized to have access to the requested services. The article on page 49 describes one of 
these authorization mechanisms called access control lists (ACLs). ACLs are lists of permissions that 
belong to certain users or groups of users. 
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DCE provides several very powerlul facilities for creating DCE clienV'servef applicaiions However, the 
interfaces to some of tfiese facifiTies are quite complex. The article on page 55 describes the HP Object- 
Onented DC€ (OOOCES product whrch is an object-oriemed library of C-^ classes that hide the program- 
inatic complexity of DCE from developers to ease ttie iSevelopment of distributed applicatiof^s. 

Transaction processing systems are usecl in large enterprises to store, retrieve, and manipuiate data 
reliably m the face of concurrent access. The HP Encina/9D00 transaction processing monitor described 
on page 61 provides an envfronment for developing distribyted OLTP (online transaction processing) 
applications. Encina/0000 uses many of the features of OCE to create rts distributed, ctient/server 
capabilities. 

One of the biggest challenges m software development fs still testing the product This challenge is even 
more daunting in distributed clienVserver environments- In the article on page 75 the authors describe 
how the testing environment for nondistributed, procedural software is not applicable to a distributed 

environment. The article describes the evolution of a reusable, ob|ect-oriented testing environment called 
the abject testing framework (OTF), Although OTF was designed for a non-DCE-based product, the con- 
cepts and tools developed for OTF are applicable to products that might be based on DCE. 

Bar code readers and magnetic strips are so commonplace today that their usefulness in areas such as 

banking, manufacturing, and retail is taken for granted. However, these technologies do have their 
limitations in that they require a direct line of sight and a relatively clean, benign environment Another 
technology called RF/ID (radio frequency identification), which is a combination of two components— a 
transmitter and a receiver — overcomes the limitations of these other technologies, The article on page 
94 describes the HP HSMS-285X silicon detector diodes designed for use in RF/ID applications. 

In today's modern hospitals patients who have to be monitored are connected to an array of high-tech 

patient monitoring et^uipment. Aware of the intimidating look of all this equipment, many hospftals are 
trying to create a more fnendly envfronment in their labor and delivery departments by reducmg the 
amount of technology at the patient's bedside. The HP Series 50 T fetal telemetry system, which is de- 
scribed \n the article on page 82, is a step m this direction. The HP Series 50 T combnies external and 
internal fetal monftoring in a lightvweight, portable transmitter 

CLLeeth 
Managing Editor 
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A highly internetworked distributed computing environment made up of clients and servers is shown in 
the background. Appearing in the foreground is the software architecture for one pair of client and 
server systems. 
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In the February issue well have several articles on the design of the HP 9D00 J-class workstations and 
K-class servers, symmetric multiprocessing computer systems based on the H? PA7200 CPU, a superscafar 
PA-RISC processor. We'll also have an overview of code-domain power, timing, and phase measurement 
algorithms in the HP 832CI3B CDMA cellular adapter. There'll be a design article on the HP HDMP- 151 2/14 
r0625-Gbil/s Fibre Channel chipset and an article on applying the software code mspection process to 
hardware descriptions. 
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In the August 1395 issue, the curve nearest the verbcal axis in Fig. 2 on page 22 should be labeled 
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DCE: An Environment for Secure 
Client/Server Computing 

The Open Software Foundation's Distributed Computing Environment 
provides an infrastructure for developing and executing secure 
client/server applications that are portable and interoperable over a wide 
range uf computers and networks. 

by Michael M* Kaztg 



TtePMlltoutecl Computing Eavironnienl (DCE) Is a $uite of 

sdftwai^ that enables net worked computers to share data 
and semces efticiently ;md securely, Tiie initial specification 
and development of LK E ttjok place in Ui89 utifter the aegis 
of the Open Software FoundaTion (OSF) througlt the OSF 
EFT (request for technology) process. Several companies in 
the conipiuer mdustr>^ incJiiding HP, contributed technologies 
t.o L)('E. MP has since relc^ised several versions of DCE as a 
product UiT HP-UX''' systems, with added cnhaticements 
paiUcularly in tools for adEiiinistration and application de- 
velopment. HP remains active in the development of future 
OSF DCE releases. 

The mtyor technologies in DCE inchide: 

• Threads. A librai> or nnii in^s ttiat tnuible severaJ paths of 
execution to exist concurrently witlun a shigle process. 

• Remote Procedure Call (RPC). A facility tliat extends the 
procedure call paradigm to a distributed en\dronmenT by 
enabling the invoc^ation of a routine to occur on one host 
and the execution of the routiae to occur on another 

• Security^ A set ot senices for authentication [to verifi' nser 
identity), authori;«ation (to control user access to data knul 
services), and account management . DCE security services 
aie described in the ailicle on page 4L 

• Cell Direct on" Seivlce ( CDS). A sei-vice tliat maintains a data- 
base of fibjects in a DCE ceU and maps their names (which 
are readable by human users) to their- identifiers tmd loca- 
tions (which are used liy piograms to access the objects). 
CDS is described in the article on page 23. 

• Globiil Directory' Sendee (GDS). A service that maintains a 
database of objects that may exist anyvvhere in the world 
and enables DCE programs to access object .s outside a cell. 
GDS is also descTibed in the atticle on j>age 23. 

• Distributed lime Service (DTS). A senice that s>iichronizes 
docks on DCE hosts with each other and, optionally, with 
an exteniai clock. 

• Distributed File Senice (DFS). A senice tliat allows DCE 
hosts to access each others tiles via a consistent global fUe 
naming hieraichy in the DCE namespace. 

Tlie HP DCE product adds several features to the OSF DCE 
offering, including: 

• An integrated login facihty that enables HP-UX login pro- 
grams to perfomi DCE authenrication for asers. This feature 
is described in the ariicle on jiage 28, 

• A DCE cell configuiation utility integrated with the HP-UX 
system adniiiustratit^n manager (SAM). 



» An object-oriented DCE (PIP OOI^E) pi^i^^raxtiBiing ei^ 

ronment that eases DCE application de\Tlopment for C++ 
programmers. HP OODC'E is descrified in the anicle on 
page 55, 

Integration of DCE application development tools with the 
Soft Bench product and extensions to these tools that sup- 
port tracing and logging of distributed appUcation acti\it>f. 

This article descrilies the DUE client/sender model, intro- 
duces DCE cells, anti provides an oveniew of four technolo- 
gies In DCE: threads. RPC (remote procedure calls), DTS 
(distributed time senice), imd DFS (distiibuied file senice), 
Articles elsewhere in this issue describe DCE security, the 
DCE directorj^ senices, and other aspects of the HP DCE 
product. Unless othenvise s|>ecit]ed^ these articles fieseribe 
version 1,4 of HP DCE/OOOO as released for Version 10.10 of 
the HP-UX operating system. 

The Client/Server Model 

DCE applications and the various components of DCE int^r- 
act according to a <'Ueni/sener model Functionality is orga- 
nized into discrete senices; clients aie users of senices ajui 
senders are providers of senices. A client program issues 
requests for senices and a sen er progi'am acts on and re- 
sponds to those requests. A progrkun may play botli chent 
and serv^er roles at; once by using one senice while it pro- 
vides another. For example, in a distributed appliiiition that 
relies on secure commLinicationt bt»th the client and sener 
sides of the a|>j)Iication also act as clients of DC E security 
senices. The cUent/sen^er model insulates the users of a ser- 
vice fiom the details of how the service is impleniente<l, 
allowing the sener implenientatior^ to l>e extended, relo- 
cated, or replicated without perturbing existing clients. 

To make the senice abstracrion work in practice, chents and 
servers must agree on how they will JtUeract. They agree on 
what requests the client can make of the sener. and for 
each request, what data will fiow l>etween them, hi DCE. 
these aspects of a senice are described in a definition of the 
client/sener interf^ice v\iitten in tlie RPC Interface Definition 
Language (IDL). Ttie DCE apjjhcation development software 
ensures that chent and sener programs will adhere to the 
interface deflnition. Given an RPC interface defii\ition for a 
senice. an application de\ eloper can build and execute 
clients and senders on different DCE implementations, and 
the resuhuig programs will interoperate correctly. 
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In acldillon to RPC mterfkees for distribiited services, DCE 
defines application program interfaces (APIs) ilial applica- 
tions Lmoke when they wish to use DC'E senices. In the 
example of the secure application tnentionecl abf>ve, ihe 
application client and the api>ltrarion ser\-er wiU both invoke 
DCE secufiiy routines pro\1dfd l)y the DCE riin-unie librarjf'. 
Hie library' wHl inieract as necessaii' with ilie DCE secunt>^ 
sen-er on belialf of Ihe appl legation program. The existent^e 
of standard i APIs for DCE services ensures the portafailitj' of 
applications across all DCE implenientations- 

DCE Cells 

DCE services are dejiloyed in adniinisti'ative units called 
celb. A cell c;ui encompass one host or many thousands of 
hosts in a single local network or in an inienietwork span- 
ning continents, llie grouping of l)osts into a cell does not 
necessarily follow physiciil network topolog.v (tliough net- 
work perfomunice charact eristics nxay make some groupings 
more practical th^-^in otliers). Rather, a celi is usually defined 
accortiing to adtitinisimti^e boiindarit^s. A cell coniaiJis a 
single security database and a single Cell Dtrectory Service 
(CDS) nanie spare, so all usei-s and applications wjthin a cell 
aj'e subject to the same adniinlstrative authority, and re- 
sources aie more easily shEured within the ceU tliaii between 
cells. 

Fig. 1 shows a relatively suuide DCE cell containing ser\ers 
and clients. Tiie tninimal set of senices in a cell (onsists of 
a security- sei-ver, a CDS seiver, and some means of synchro- 
nizing time among the hosts. In this celi, the security and 
CDS databases are replicated for increased performance 
and reliability, so there are two security sen^rs and two 
CDS servers. The Dt*E time servitx^, DTS, is used to synchi'o- 
nize clocks throughout the cc^l with an external time source. 
Dllicr DCEl ser\nccH such its 1 JT'S a^id (]DS fGlol>id Director/ 
Senice) need not be configured in li minimal DCE cell but 



can be added at any time. A DCE-based application is 

installed in the cell in Fig. 1, wiih an application server run- 
ning on an HP iJOOi) Series 800 sen er and application clients 
running on PC^s and w orkstations, Bnallj. each host m the 
cell has a DCE run-time libraj>^ and rmis DC E client daemoiis. 

Threads 

In a distribuied ennronment the need often arises for one 
program to comniunicate cfincurrently with several otliers. 
For example, a server progiam n^ay liandle re<|uests from 
many clients. The DCE threads facUitTp^ provides the means 
to create concurrent threads of execution within a process 
and hence eases the design and erdumces the [lerfomiance 
of distributeti applications. Tlte threads facility is not itself 
distribuied, l>ul nnually all distribuied senlees in DCE rely 
on threads, us do most DCE-based at j plications. 

POSDC (Portable Operating System hiterface)^ has defined 
an indiistr>^-standard progrcuimung interface for writing 
multitJireaded aptdications; the Pf )S1X 1003.4a s-piecification. 
DCE thi-eads is a user-space implementation of Draft 4 of 
this specification. 

One way to introduce the ntJtion of a thread is to describe 
an ordinary' suigied-tJueacied process and contrast this witli 
a multitJueaded process. A process is a running instance of 
a program. Wheu a process starts, the text of tlie program! is 
loaded into tlie adciress space of the process and then in- 
stiuctions in tlie program text aie executetl until the |>rocess 
terminates, Tlie instructions that iue executetl can be tliought 
of as a patlt or thread of execution through die address space 
of the process. An orditmr^' i>rocess can thus be considered 
to t>e suigle-lhreadetl 

A threads facdity allows several threads of execution to exist 
within one process. An initiid thread exists when a iirocess 
starts, and tiiis thrt^ad caji create additional tlireads, making 
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the process multitJireadeti. Eac^h thread executes Indepen- 
dently and has its own stark. However, 1 lie threads in a pro 
cess share most process resources, such as user atid group 
identifiers, working directories, controlling tenniaaJs, file 
descriptors, global variables, and memory allocated on the 
heap. 

Resource sharing and concurrent execution can lead to 
several pcrfomi^mce benefits for multithreaded:! programs: 

• Threads can be created, synchronized^ antl terminated 
much more efficiently than processes. 

• If one thread blocks, waiting for UO or for some resouice, 
oilier threads can eoni inue to execuie. 

• A server program can exhibit better responsiveness to 
chents by dedieathig a sepaiate thread to each clierir 
request. Tlie sener can accept a new request even while it 
is still executing older requests. 

• On a multiprocessor troniputer, several Uireads within a 
process can run in parallel on several proc^sons. 

Of course, the execution of t lireads Ln a process can be truly 
concunent only on a computer tliat has multiple processors 
and has a tJireads iniplenieiUation that can take ad\ antage of 
multlprocessmg (even then, concurrency is limited by the 
number of processors). In reality, the ttireatis in a process 
take turns executing ac^cording to a scheduling policy ajul a 
scheditlmg priority diat aie assigned to each thread. DetJenri- 
mg on the policy that governs a thread, the thread will run 
until ii blocks, until it consumes a time slice that was allo- 
cated to it. or luitil it \ oluntiuiiy yields the processor. A con- 
text switch then occurs, and the next thread to execute is 
chosen from a queue of threads that are ready to run, based 
on tJieir priorities. 

Tlireacis programmers can use condition variables to syncluxi- 
nize threads sf^ that a thread will nitt only after a specified 
condition has been satisfied. A thread vmi wait on a ccjndil ion 
vtuiable either for a specified time to elapse or for another 
thread to signal that variable. The waiting thread does not 
reenter the leady queue mitil die condition is satisfied. 

Because threads run concurrentJy and sltare process re- 
sotuces, programme IS must protect regions of corle that 
access shared resomTes. For example, if a context smtch 
occurs Ln code thai manipulates global variables, one thread 
may have undesired side effects on another thread. Tlie 
threads AI'I allows progiannuei's to use mutual exclusion 
(mutex) h>cks to prevent such eftects. Only one thread can 
hold a given nuitex lo(*k at m\y time, imd miy other thread 
tliat attempts to take the lock will liiock until the lock is 
released, so only the thread that holds the lock can execute 
tire critical region of <ode. 

Like global data, static data can be a conduit for side effects 
betw^een tlrreads when a context switch occurs, and this 
imposes ai\other constraint on code that executes in nuilti- 
threaded processes. Routines that can be called by multiple 
threads mu.st not return pointers to static data. 

The requirements mentioned above for code ui muliiflu'eacled 
prograitis apply not only to DCE executables and IKE iippli' 
cation prograiris, but also lo any libraries used by those pro- 
grams. A libraiy is considered tliread safe to the extent that 
it behaves correcdy when used by a multithreaded program. 
The HP-UX operating system defmes several levels of thread 
safeness lor Ubraries. Tlie HP-L'X C hbrai*y, for instancet can 



safely be called by several threads in one program, whereas 
some other Ubraries can be called by only one thread per 
program. 

A kernel-space implementation of liie final POSIX t lireads 
specification may ultimately replace the user-space imple- 
mcntaiion of Diaft A that is CLirrently suppUed with IIP DCE, 
Kernel threads would niakc^ tnie concuirency possible on 
multiprocessor computers and probably improve peif or- 
mance on uniprocessor machines as well. 

Re J note Procedure Call 

Thf remote procedure call (RPC) facility" is tiie basis for aO 
E)CE chent/sen'^er commtmications and tlierefore is fmida- 
mental to the fhstribution of services in DCE applications 
and in DCE itself. 

The RPC mechanism enables a procedure invoked by one 
process (tlie client } to be executed, possildy on a remote 
host, by jiiuither process (the server). Tiie client and server 
hosts need not have the same operating sy,stem or the same 
liardware arch i tec? ure, However, they do need to be able to 
reacli eaf*h other via a transport protocol that is sup pone d 
by tlie DCE hupiementaiions on both hosts. 

DCE IIPV conft>nits to a set of siJccifications (^ollecti\ely 
known as tlie Network Computing Architecture (N(A). The 
NCA specifications define the pi'otocols tJiat govern the mter- 
action of clients and senders, the packet format i^n which 
RPC data is transmitted over the net\^ r irk. and the Interface 
Definition Language (IDLJ that is used to specify RPC inter- 
faces. DCE RPC is btLSed on Version 2 of NCA. Version 1 of 
NCA was a set of architecture specifications for another 
remote procedure call facility, the Network Computing 
System (N( S), which has been in use on the HP-IX operat- 
ing system and other i>lattVmns since the late lOSOs. f>CE 
RPC evolved from NCS, supports the interoperation of NCS 
and DCE applications, and offers features that assist m tlte 
conversion of apph cations from NCS to DCE. 

NCA defmes t\^^o RPC protocols, one for use over comiee- 
tion-based transports (called NCA CN RPC ) and one for use 
over datagnun-based transports ( NCA DG RPC ), Tlie con- 
nection-based protocol relies on the underlying tnuisport to 
manage connections betw^een clients and sen ers, whereas 
the datagram-based protocol assumes an unrelialile trans- 
port <md performs its own connection management. A DCE 
implementation can sujJiJoil each of these protocols over 
severjU ti*ansports. HP DCE t lu^rently supports NCA connec- 
tion-based RPC over TCP/IP ami NC A datagram-based RFC 
over IT)P/IP. The NCA protocols ensme that remote proce- 
diuT call semantics are not ^iffected by tlie underlying trans- 
port used. This chaiaclierisfic of NCA, sometimes referred to 
as tratispon independence, is essential for the portability 
and inierope J ability of DCE and DCE applications o^er 
many types of netw^orks aitd computers. 

How RPC Applications Work. To understand how an HPC 
apt>ht'iiiiou works, tu^t imagine an oniinaiy rK:indistnbuted 
program consisting of a maui modulet whicli peifonns vari- 
ous initializarion tasks and hmidles user interaction, and a 
second module. wMfh does iJie real woik of the apphcation 
such iis interacting \\itli a database. Tlie main mofiule am be 
thought of as a client of the services implemented and 
prox^ided by tlie database module. In DCE terminology, a 
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module tliat implements a service is called a manager, and 
the set of manager routines that tlie client caUs constiiait^ 
the interface lieiweeJi client and manager 

ng. 2a illustrates this simple program and a representation 
of the interface between the c!ie-nt ami the manager pieces. 
Note that the niodularization of this program demands only 
that f he client and manager pieces adliere to the declared 
signatiire (calling syntax) of each routine in the interface. 
This implies that the manager module could be replaced by 
an\' otlier module containing routines that have the same 
names, return the same data t\pe, antl jjass tiie same argu- 
ments. In an ordinary C application, mutine signatm^s are 
typically declared in header files ttiai get included in other 
modules. 

Now imagine that this application is t<5 t>e distributed so that 
the database ttianagement cwie ex ecu res on a mini computer 
and the user mterface code executes on a grapliical work- 
station. Tlie fu-st step in building a t)CE RPC application is 
to write an IDL interface definition. An interface definition 
si>ecifies tlie ITLTD ( miiversal unique identifier) and version 
of tJie interface, declares the signatm'cs of the operations 
(routines) in the interface, and declares data tji^es used by 
those operations (Fig, 2b). The declarations of tjpes lUkI 
operations in an IDI. file resemble those in a C header file, 
but ajt IDL file contains additional information required to 
make (he operations callai)le \1a RPC For example, tlie op- 
eration tleclaj'ations in an IDL file aie embeUished with at- 
tiibutes tJiat specif\' explicidy whether the routuie's aigu- 
ments are inputs or outputs, so that when the routine is 
called, argimients pass over the network only in the direc- 
tion needed. 
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Fig- 3. Flow of events when a client program calls db.lMkwp on tlie 
.server. 

The next step in building a distributed application is lo com- 
pile t]ie mterface definition with tlw DCE IDL compiler 
(Pig. 2c). The IDL compiler takes the IDL flic as iaput mid 
emits three C souicc files its output: a c Ueni sttib motiule. a 
sender stub module, and a header file. Tlie IDL compiler 
derives the nimies of the emitted files from the name of the 
IDL file. 

Tlie chent stub presents w the applicatif>n client module the 
same mteriiice that the matiager module did in the local case. 
For example, if the max^ager rnodnle contahied a routine 
called db, lookup t so will t:lie chent stub. Likei?^ise, tlie ser\er 
.stub presentii to tlie manager nxoduJe the same interface that 
the application client module (hd. CrjutinuuTg the exatiiple. 
die server stub calls tlie dhjookup routine hi the inajiagerjusl 
as Uie client did in the local case- Tlie fieatler file contains 
the decUuations needed to compile and link I he client mid 
seiAcr progriuns. 

The final step jti huilding the application is to link these 
(Revolt )pet-wntten ami IDl-rCompiler-generated modules into 
I wo programs: a client program consisting of the old client 
module and the client stub and a server program made up of 
the old manager module and the server stub. (This descriji- 
tion is rather simjjiified. In reality, a number of 1)(T' library' 
APIs aie typically invoked by apjjlication rode iit brjth the 
chent and sencr ijnjgrams,) Boih i>rt>grams ;iie dytiamjcally 
Ihiked wltii the DCE shared library; which must be present 
as part of the DCE nm-time environment on the client and 
server hosts. 

Fig, 3 describes the flow of events that occur when the clienl 
prognim calls dbjookup. Tlie call to db_loDNup is tesolveiJ in 
the client stub module i . Tlie dbjookup routine in tJte client 
stub mjirshalls die operation*s input parameters into a request 
tittlTer and then hivokes routines in tJie DCE library to send 
the retjuest to the server host z . On both the sending and 
receiving sides, RPC code in the DCE library deals as neces- 
sary with any issues involving ilie tinderl^ing transjiort, such 
as hagmentation and window sbes. W]\en the sen'cr j)rograin 
receives I be retincst, iKK libraty code rails the dbjookup 
routine in the server stnb mothile I , whUli nmiuu-sballs tlie 
Uiput parameters and passes them to the act ual implementa- 
tion (jf db_fookjp in Iht^ application manager module 4j* 
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Ulipn the manager routine retums 5 , the server stub mar- 
shal IsS the operaHon'i5 ftiilpul paranipters and a retioTi value 
into a response L>ulTer mid invokes DCE library' routmGs to 
send the response to the client 6. library code on the clienl 
side rereives the response and returas ronfrnl rtj \]\i' client 
stub db^lookup routine t , which finally ujuiiit^shidlN ihe out- 
puts and returns to the main clienl module i - 

RFC Protocols, UCE RFC clients and servers conin^unicate 
ovei- a network by exchatiging messages, such as the request 
and response messages desenherl in Fig. 3. Each message, 
called a protocol data imit fPDUj, consists of up lo duve 
paits: 

• A heatler, which contains RPC" protocol control infomiation 

• An optional body, which contains data 

• An optional authejiliratiou verillen wliich contains data for 
use by an authentication protocol. 

The FDli itself is of coui"se encapsulated by control informa- 
tion specific to tlie transpoit and network underlying a re- 
mote^ Ijrocedure call. For example, when a datagram-based 
Rl*C PDU is transmitted as a UDP/IP packet, it is preceded 
by tllJP/lP header infoiiuation. 

A few examples of mfor-mation that might be carried m the 
header of a DCE RPC^ PDU include: 

• ^Hie version of the DCE RFC protocol in use 

• The PDC tyije (Both connection-based RPC and datagrmn- 
bas^'d RPC define request and response PDU tyi^es. In addi- 
tion, each RPC protot ol defines several PDU types specific^ 
to tlie |)rorocol Fm exjuuple. bet -at is e daiagrajn-bascfl RPC 
implements its own connection tnanagement, i1 defines 
PDU types for pings and acknowledgments.) 

• The ITUID til at identifies the inteiface being used 

• The operation number tliat identifies tlie operation being 
called within that interface 

• The UU ID liial identifies the object on wliich the operation 
is to be performed 

• A label that identifies the data represeniation f«>niiai in 
which the PDl ' header attd body data are encoded 

• Tlic length of tiie PDU body. 

Many PDU type^ setve only tt> convey ijrntocol contrril infor- 
mation betw^een a client and server and iience liave tio hotly. 
Request and response PDUs, of course, do have l>odies con- 
taining the input and output paiameters of the remote pro- 
cediure call. These parameters are encoded accorchng to a 
transfer syTitax identified by the data representation fonuat 
label in the lieaden DCE RPC currently specifies only one 
transfer syntax, the network data representation (KDR) 
syntax. 

NDR defines the representation of each IDL data typp in a 
byte streain. Por scalar tyq^es like integers and fioating-jjoint 
numbers, NDR acidresses issues such as byte (udtT and 
floating-point format. For constructed tyi>es like arraySt 
structures, and imions, NDR sets rules for flattening data 
into a byte stream. Thus, the set of input and output values 
in e\ ery remote procediu'e caO lias a b>te stream represen- 
tation detenniued by NDR sjntax. The b>te stream is passed 
between client and sen^r as the body in one or more re- 
quest an<i response PDUs. Table 1 lists the data ijpes stip- 
ported by RPC, 



Some scalar data types have several supporteti fommts m 
NDR. hifegers, for example, may he in eitJier fiig-endian 
{most significant byte first) or UtUe-endian (teas! significajil 
byte first) format. For these i>nmitive tyi>es, tJie format that 
govems a particulffir PDU is indicated as par! of the data 
represeniaUoii rorrnai label In flu ■ IM)E lieirden Oiwuiy given 
hardware iirc tut ectu re. the DCE lilirmy will send outgoing 
data in tlie representations nati\-e to tiiai aiciatectiire. If tiie 
receiving iiost lias different native representations, its DCE 
librar>^ v^ill convert incomiitg data (for example, by s^^'aiJi'jing 
bytes in integers) as necessary. DCE RPC tlitLs has wiiat may 
be called a multicanomcal apjiroach ro data representatioiu 
This approach tends to minimize ciata conversion, and in 
particular, two hosts of tlie same architecture can usually 
communicate without ever converlmg data. By contrast^ if a 
data representation scheme dictates a single canonical fonnat 
for each scalar ty|)e, and the client and server hosts share a 
common formal other thati tlie canonical one, data will be 
converted botli when sent and when ret eived. 

The third part of a DCE RPC PDU, the authentication veri- 
fier, is present only for authenticated remote procetlnre 
c:alls. It <^oiitains data whose format anil content depend on 
the authentication protoctil being used. Use of the authenti- 
cation verifier is exT>lained further in the description of 
autlienticated RP<; beitiw. 

ClientySen^er Binding. A key question in the design and imple- 
metitatioii r)f a DCE RPC ai:>plication is, how will the client 
locate an a|>proijriate servei? When making a RMnole [jroce- 
dure call, a client [irogram must specify to its DCE nm-tlme 
library the location of a sender that criii perform the requested 
operat ion. The seiver location incorporates an RPC protocol 
sequence (the combination of NCA protocol and network 
protocol), a neti^ork address or host name, and an endpomt 
(for the IP protocols, tlie endpoinl is simply a port number). 
Tliis infomiation is encapsulated in a stnicture called a bind- 
ing, A Innding may tilso include the I CID of the object to be 
operated on. it any, and auiheutit ation and authoriscaiion 
infomiation, if the call is to be authenticated. 

The RPC API supports a range of techniQues for obtaining 
anti manipulating bitKlings. Most applications either con- 
slttJCt a texUial retjresentaiion of a bindhig (called a string 
binding) Irom infonnation siip])lied by the user orol)tain a 
binding from a name service. 

A string bindii^g represents in a textual fonuat the object 
UCID and serv^er location portions of a binding. For exam- 
ine, in the string bindmg: 

t858c02c-e42b-1Ue-a344 0800093579S9@ncadg_Fp_udp: 
192.1 8,59.1 31 [20011 

the object IT^IJID appears in tiie standard strijig format for 
LUIDSt the ncad9_ip_ijdp protocol sequence spc^cifies the 
NCA DO RPC protocol over CDP/IP, an Internet address 
identifies I he server host, tmd a pon numl>er specifies tlie 
endpoint on which the server is listening. (The object ULTD 
and the endpoint are optional.) 
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Tallin I 

Data Types Sypparted in RPC 

Primitive Data Typts 

Integers 

Flrjaiing'iH)im 
luufiiliers 

Charac:^ters 

booleartT 

l^p^ A type usually used m arrays tir structures 

to transmit opaque datiL Data of t3i>e byte 
is guamnieed nut to utitiergo format 
conversion, 

VOiiJt A tjpe used for of)c*rations that return no 

value, for null painter constants, and ft ji 
context, handles. 

handSe_tt A type used lo store hinding infomiation 

in a foniiat rhat is meajiingfii] to die rut- 
time DCE library but opaque lo appMca- 
tiotis. 

error_statiis„i? A type used lo store DCE status values. 

International A set of types constructed from the byte 
character p ri miti ve that sup \ )ort i n t emat ional stan- 

typ^es dards for character and string representa- 

tion. 

Constructed Data Types 

Structures 



Unions 



Enmnerati 
Pipes 

Arrays 



Strings 



Pointers 

Context 
handles 



This tyjje is somewhat like a C union oper- 
ation, but entbeds a discriminator, which 
at ruti time specifies which niembci- of ilie 
union is stored. 



An open-ended sequence f>f i'icnu^nts of 
(jne tyi>e that is used tcj hansfcT liiilk dala. 

An ays may bf one-din>ensional or nudtidi- 
inensiojial and may be ot Hxeti size, con- 
fonnaiit (the array size is determined at 
run time S, *>r varying (a subset of the aiiay 
{{> be transmitted is determined at rim 
time). 

Strings arc one-dimensional nnll- 
terminatcd arrays of characters or bytes. 



Context handles are not really distinct 
lyjH's, litn fiointers to word data. Tliey kuv 
speritl<nl l>y af>p lying tlie context_ handle at- 
tribute to a parameter A context handle 
denotes state infoi-mation that a server 
nuuiager wiii niainiain cin behalf of a cli- 
ent. Use of a context handle allows Ibis 
state to pei'sisi across stn eral remoie litii- 
cedure calls from the client. 



String bindings are ea^' to generate and manipulate and are 
suitable for ai.)plications in which the user of the client pro- 
gram knows in advance the kxraiion of the desired servr^er 
The user can supply server location infoniiaiion lo the client 
program interactively or as a cominaiui line argument or %ia a 
conHgtiration file, and clieni application code can invoke 
RFC API routines to comp4>se a string binding imd ihen gen- 
erate a binding liandle ihat can bepasseil to Itje HPC rmi- 
time library. 

Siring binctings arc welhsuiie<1 for some RK' applications, 
but many dislxibuieti senices require a more flexible and 
transptireni way of esiablishiiig bindings, DCE RPC pro\ides 
an application interface, the RFC name sei-vlce independent 
(NSI J Al^h through wliic*h servers and clients can export and 
impoil biJiding infonnation to and from a name senice. The 
use of a name service to store binding ijd:brmation insulates 
< [ienis from knowledge of where oljjec:ts ^md ser\'(^rs reside 
The client has only to sjiecify im otyect and km interface and 
then use die name senice to IcKik up the location of an 
appropriate server. Thus, the reloc:ation or replication of a 
sender can be made transparent to clients. 

As its name suggests, the RPC NSI interface is independent 
of any parliculai- name semce, llius, applications coded to 
this irnerface will potentitilly be ijortable across DCE imple- 
ment at ions incori>orating a \anety of nimie services. In lite 
current HP DCE implementation. DCE CDS underlies the 
RPC NSI iiiterface, so that the generic RPC name service 
routines invoke corresi^omling DCE CDS rout ines. Ir\ (jrinci- 
ple, anotlier luime service such as X/Open Fetlerate^l Naming 
(see article on t>age 28) coidd supersede CDS in il^e DCE 
nm-time environmentj and existing KPC applications would 
("ontinue to work, 

DCE; security, whic^h is described in th(^ article on (lage 41, is 
iui example nf a smnit c that lakt^s advmitage of b<»ih RPC 
Innding tiit'lhods, TUe serurity clieni rod(* in the [KB nin- 
time librajy can bind to a security seiver cither through RPC 
name service calls or through a string binding generated 
from a c*onfignr;ilifiii fik^ on the client iiost Hie configuration 
file solves a boolstiap|)irig problem by making I he si'curily 
senice locatablc even when CDS is imavailable. 

Authenticated RPC. Thi* alnlity to jjcrfonn authenticated RPC 
i.s crut iai to the usefulness of DCE in the real wurhi, where 
file in! egrity mid privacy of data often must be assurtxl even 
when the data is transmitted over physically insc(Mtre net- 
w^orks. DCE supports several levels cdauthenticatefl RPC so 
that aj^iilications will incur only the perfornKuice overhead 
necessitated by the tlesireci degree of protection. Tliese 
levels include: 

• None. No inotection is performed, 

• Connection, An encryjition liantlshake occurs on the first 
remote procedure call betw^een the client and the server^ 
excl ranging authenticated identities Tor client and server. 

• Call In addition lo connection-level ]irolection, ihc inlegrity 
of the tlrsi PDC of each reqnesi and response is verified. 

• Thicket. In atldition to call-level proiecliiin, replay and mis- 
ordering detection is applied to each PDII, ensuring that, all 
data received is from the expecteti sender 
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■ Packet inlegrity. In addilion to packet-level protection, the 
integrity of every PDli is verified. This level can be thought 
of as protection against tampering. 

► Packet Privacy. In addirion to packet-integrity-level protec- 
tioEj all remote procedure call parameters aie encrypted. 
This level can be tlioughl of a.s protection against t)otli eaves- 
dropping and taiupt^ring. The [privacy protection level is not 
available in ail DCE implementations becanse of restrictions 
on the export of encryption technology from the United 
States. 

Wlien data mtegrily is prbtected^ tJie sender computes a 
cliecksnm of the data, encrypts the cheeksuni, and inserts 
the encii^pted checksum iti the authentication-verifier por- 
tion of the RPC PDI" for vciHication by the receiver. WTien 
data privacy is protected, the sender enciypts the actual 
paratneieiT^ hi the EPC FDU body, and the receiver decrypts 
them. 

The authenticated RPC facility is intended to atx-onunodate 
more than one authentication an<l auiboriicalion sen'ice. A 
serv^er program registers with the DCE ntti-tiine libiaiy the 
authentication protocol ji suppons. A client specifies an 
anUientication protocol an authorization protocol, and a 
protection level in its ijinchng. Wlien the server receives a 
reciuest, application code in the manager caii extract authen- 
tication and authorization info mi ation from the request. IIP 
DCE currently supports only the shared-secret authentica- 
tion protocol hnplemented by DCE security. 

Distributed Time Service 

The di^itribntetltinie .serxice, or DTS, is a distributed ser\lce 
that symlironizes the clocks of all hosts in a cell with each 
other and, optionally, with an exiemahinie source. In a typi- 
cal cell configuration, a few hosts (perhaps three ) run a DTS 
sender daemon, and all other hosts nin a DTS client daemon 
called a DTS clerk. One of the DTS sender hosts luay also nm 
a daemon called a time provider wliieh obtains time from an 
external soiitce, DTS clerks and seners coinniimicate via 
RPC and also rely oJi CT>S ami sectirity seivices for naming 
and authentication. 

Clock synchmnixation is essentia for the operation of a DCE 
cell. Tlie various methods used in several DCR technologies 
to cache or rephcate data, for example, require that clocks 
agree closely. 

hi addition to the daenunis thitt synchronize clocks, DTS 
includes a hbraiy ofptogranmiing interfaces tiial allow ap- 
phcations to generate ;md manipulate time values in binary 
format or in ajiy of several standai^d textual fonnals, DTS 
associates an estimated inaccuracy with evety rinie value, 
so a time \alue can also be treated as an interval tliat is 
hkely to include the correct time, hitemally. DTS al^says 
keeps time values in tlie I'niversal Coorditiated Tune (ITC) 
standai^d governed by the hiteniational Time Bureau. The 
DTS API allow^s apphcations to display time values in local 
time zones, 

OTS Clerks. Most hosts in a DCE cell run a DTS clerk. A clerk 
periodically (at a randomized intenal of roughly ten minutes) 
obtains time values from DTS senei^ in the cell The clerk 
then reconciles these resii hs to c o input e a single value and 
inaccuracy that it applies to the local host. This computation 



takes into account tlte inaccuracy of each server and an 
estimate of the time lost to processing and conununi cations. 
If one DTS sen-er has a faulty clock I hat tlisagrees sliatply 
with the others, the clerks will ignore that value^ preventin^^ 
the faulty clock from influencing tune throu|^iout the cell. 
Usually, the time intenals from the servers (time values plus 
or minus inaccmacies) inlersect, and the computed time lies 
within tills intersection (see Pig, 4). 

The clerk ac^usts time on tlie local host in such a w^ay that 
the clock is coo'ected gradually and continues to advance 
monofonically. It is especmlly important to avoid a sudden 
backw'ard correction because many softrw^are systeius, in- 
cluding some components of DCE, depend on the mono ton- 
icity of the clock, in most computers, a hardw^are oscillator 
generates an interrupt at some fixed uiterv^al, and this inter- 
rupt, called a lick, causes the operating system to advatice a 
softw^are register by some increment. Slight inaccuracies in 
oscillators cause clocks to drift relative to each other To 
acLjust time, rather titan w^rite the computed correct, tittle 
directly to tlie clock register, the DTS clerk changes the in- 
cretnetil by which the register advances with each tick. In 
effect, the software clock rate is increased or decreased to 
bring the local liusi itito agreement with tiie servers. 

DTS Servers, DTS seners can be configured in two ways: 
If a DTS time provider is nti\ning on one of the serv^er hosts, 
the DTS servers on all other hosts synchranb.e wdth the DTS 
server on that host (roughly eveiy tw-o minutes ). Thus, time 
obtained by die time pro\ider from an external soiurce is 
propagated to the DTS servers in the cell. 
If there is no DTS time provider in the cell, tlie DTS servers 
s^Tichronize wath each other (roughly ever^' two minutes). 
This process is similar to I he one used by clerks, except tliat 
each DTS server also uses its ow^n time as one of the hipui 
values. 

External time sources can include telephone and radio ser- 
vices, sue 1 1 as those operated in the United States by the 
National Institute of Standards and Technology and vaiiotts 
satellite se it ices. DTS can also use an Internet netw^ork time 
protocol (NTP) sender as an external time soiuce. Thougli 
DTS and NTP cannot both be allowed to contiol the clock 
on any one client host, the DTS NTP time provider can be 
used 10 s>iiclironize a set of DTS-controlled hosts witli a set 
of NTP<-ontrolled hosts. 
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DTS sen'eis and time providers attempt to compensate for 
processing and eommunications delays when they obiain 
time \ialues, jtisi as the DTS clerks do. 

Distritiuted File Service 

As the I.'NIX operaiing s>stem has spread from standalone 
compmers lo networked workstations* the need to combine 
file systems iti heterogeneous coUectioas of conipurers has 
groTp^Ti, A few soJutions ha\e evolved to meet tlus need, 
intruding the Network File System ( \FS) ftom Sim Micro- 
systems and tlie Andrew File S%^em (AF^) from Traiisarc 
Corporalion. The Distributed File Service (DFS) is a succes- 
sor to AFS that is inlcgmted into DCE- 

DFS adds a global filespare to the DCE namespace (see tlie 
article on page 23 for a description of DCE naming k File- 
sets, the logical miits of file system manipulation in DFS, aie 
mounted %viihin the DFS filespace for access by DFS clients. 
DFS cleanly separates the logical and phj^sical aspects of 
file <ienice. so Hiat a aser can always access a flic in the 
DFS filesimt^e by rlie same tiame, regardless of where the 
file or tJie user jiliysically resiiles. AU l)¥^ file sysleni opera- 
dons comjily \'^'ith the POSDC 1003.1 specifications for file 
access semantics. A token-based file access protocol en- 
sures that readers and \'^Titers always see the latest changes 
lo a file. 

DFS is a distributed service whose m^or components are a 
cache manager that mns on DFS client hosts, a fiieset server 
and file cxpoitcr that nm on DFS scrv er hosts, and a fileset 
location server that can run on any DCE host. Conmiunica- 
lioo among these components is \1a RFC; some DFS pro- 
cesses run in the operating system kernel and make use of a 
special in-kernel iniplementation of the datagram-based RFC 
protocol Fig. 5 illustrates the relatioiisltijJS between these 
processes and the logical roles that a host can assume In an 
actual DFS deploymem. one host may play ooe, twr^ or all 
thr(H^ of these roles. 

( )i her DFS software in the IIP DCE prodtict mcludes a DFS- 
to-NFS gateway which exports the DI^ filespace to NFS, 
providing seeure access to DFS files from hosts outside a 
DCE ceil ait update service that keeps files In sjTichroniza- 
Tjfju between hosts, a basic overseer server that monitors 
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Fig. 6, The rekitionship be i we- en E3FS aggrtgaiL^s and fileset s, 

DFS daemons on each DFS host and supports variouis remote 
admimstrari%'e operations, and other acknhiistrative utiUties, 

Server support for some Dt'^'S feat tires is detiendeot on the 
level of fiinc'tionaiily providetl by I he lot al file system sort- 
ware on die sender host. For the i>uipoHes of this ailiele, a 
lockil file system cati be chissified as either a tradiLitaial 
UNIX file system or an extended tile system tliat offer.s more 
adv^anted hmrtionality. DFS seiver softwine can supjiort the 
fuU range of DPS featiires onJy if the underlying tile system 
provides extendetl fiiv systcMii funetionalily. liP-l'X file sys- 
tems currently fjrovick^ only VNIX fiJe systdu functionality, 
so lll^-f. X DFS sender hosts do not support tht DPS features 
that det)end on extended file system fuuctionaiit\. If DFS is 
defjloyed across a heterogencHjus sel of plat Tonus, DPS 
server machines from other ventlnrs may have file systems 
that do allow full DFS sni>port> When aecpsslng OJes frorti 
sucli a nuicbine, an nP4 'X DMS clieul hosf can take athan- 
tage of the entire DF8 featine seL 

Aggregates and Filesets. The DFS Hlespaee Is a hiermchy of 
tliivi luf ies luid hk's duit forms a single logical subtree of tlie 
DCE namespace. Tlie root of the DFS filespace in a cell is 
ti)e dire<'tory whose global name Ls /... /<CEll-name>/fs. This 
directory can also be accessed from within the cell hy the 
local name / : /fs or l»y the s]'jeciai prefix /:. The direetones 
and files in tlie DFS filespace cim reside physically on many 
chl'feient DFS server fiosts in the DCE cell. T^vo tyjies of 
DF'S resources reside on f^FS server hosts: aggregates and 
niesets (see Fig. 6). 

Au aggregate is the DFS reference to the physicai entity 
frotn which one or more file sets me created. From du.^ ^>er- 
spective of tiie local operating system, tim entity is a logiciil 
disk nianaged by loc*al file system softwai'e. For example^ an 
aggregate coulrl refer to a logical volume or to a fjhy.sical 
panition t>n a disk. 

A fdeset is a hierarchy of directories and files Uiat are storcnl 
i n ;y 1 aggrega t (^ , A next e 1 1 d t m I fi I c sy s i e i u ; iggrcgiu e < -^m sto re 
several extended Hie system fdesets, wheretis a UNIX file 
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system aggregate can store only one UNIX file system file- 
seL Each fjle^^e! has a nanie (assigned hy an adniinislrator) 
anci a iimnber (generated automatically) Lhat are unique in 
the DCE cell. A DPS client uses the fileset name to locate 
the fileset, and Oiiis the fdes it contains, hy looking up the 
nanie in the fileset location datab^ise. 

Many DFS features involve manipulations of filesets. The 
operations an administrator can iierfomi on a fdeset include: 

• Mounting it in the file space so lliat DFS clients can see its 
fdes 

• Barking it up 

• Setting Its quota so that when several filesets reside in one 
a^regatc, the disk space in ihe aggregate is not dispropor- 
tionately consumed by one rUesei 

• Moving it to another aggregate to balajice the load among 
aggregates and DFS sen er hosts 

• Replicating it lor perlonnance and reliability. 

The last three of these operations are supported only by 
extended file system aggregates. 

Mounting a fileset in the DPS Olespaoe makes the tree of 
directories and fdes in the flleset visible to DFS clients. Tlie 
fileset is mounted at an entry in the filespace^ called the 
mount point, which then names the root directory of tlie 
fileset. For example, a fileset containing the home diiectoiy 
for the user Joe might be named users. joe. An administrator 
mighl decide to mount the home directories for all users 
untier one directory in tJie DFS filespace, such as /, Jccell- 
name>/fs/users- The admlntsi r ator would issue a command to 
mount usersjoe att say, A.7<cell-name>/fs/users/joe. Joe could 
then use this pathname to access his home directory from 
anywhere. DFS momit points are pennanently recorded in 
the file system as special symbolic links and, miMke UNLK 
file system mount points, need not be recreated each time a 
host boots. 

A DFS fileset can also be locally mounted, by the UNIX 
moimt comniand m tlie directory hierarchy of tlie local host. 
For example, the users. joe fileset could be moimted at /users/ 
joe. A file in a DFS fileset tlius can be accessed by several 
names: a local pathname specific to the local host (like 
/jsers/joe/maittxtj, a pathname relative lo the local cell (like 
/;/users/joe/maEl.txt), and a global pathname (like/..7<cell fiame>/ 
fs/users/joe/maiLtxt). DFS guarantees that operations on the file 
adhere to POSIX semantics, regardless of which way fiie file 
is accessed 

DFS Client Components. Each host that accesses the DFS iile- 
space runs a set of t)FS clieru processes that execute in the 
kernel, wliich aie collectively called tlie cache manager. The 
cache manager interacts with the client host kernel, which 
makes file requests, and witli file exporters, wliich service 
fde requests. It also maintains a local cache of files that have 
been accessed^ The cache can reside eit-her on disk or ui 
memory. 

\\lien a file in the DFS filespace is referenced, the virtual file 
system layer of the kernel invokes the r>FS cache manager 
to handle the reference. Tlie cache manager checks to see 
w^hether the local cache can satisty the requested mode of 
access to the requested file. If not, it consults the llleset 
location sender to locate tlie file exporter that manages the 
requested file and then forwards the request to the file 



exporter. All data returned by file exporters is cached to 
reduce load on the servers and on the network. 

The interactions of the cache mans^er with fileset location 
sen^rs, file exporters, and the local cache are entirely hid- 
den from the operating system on the clierU host. To the 
user, accessing a DFS file is no different Ironi accessiiig a 
file in a local file system. 

DFS Sen/er Components. Each DFS server host runs a set of 
fJFS processes tliat provide access to its filesets and files* 

The filesel seiner process responds to fdeset management 
requests from administrative chents for filesets residuig on 
the DFS server host. Tlie RFC mterface exported by the file- 
set server includes operations to create and delete filesets, 
dump and restore them, and get and set status information. 
Fileset sen, eis cooperate with each other, with fileset loca- 
tion serv^ers, and witii file exj>orters to implement operations 
such as fileset movement and fileset replication. 

The fde exporter process responds to file access requests 
from chents for fdes residing on the DFS server host. The 
file exporter is responsible for reading and wTiting data to 
the file and for maj^aging attributes of the file such as its 
modification time. 

DFS Frieset Location Server, DFS keeps hYformation about tlie 
current state of all hlesets in the fileset location database. 
This replicated database tiacks the aggregate and the DFS 
server host at which each fileset resides. A set of daemons 
called fileset location sei'v^ers maintains the fileset location 
database. Fileset location sen^rs can nan on any hosts in a 
cell but are typically configured to nm on a subset of the 
DFS sender hosts. 

If a DFS client encoimters a DFS moimt point wMe resohing 
a [pathname, it contacts a fileset location seiver to obtain the 
cuiTent location of the fdeset momited at that mouiU point* 
Given the fileset s host and aggregate, the tJFS client can 
then issue a file access request to the connect file exporter. 
Because clients look up fileset locations dynaimcally, a 
tiles el can t>e movefi or replicated without usere and app Il- 
eal ions Ijeing aware of the change. DFS fileset servers auto- 
matically update the fileset location database whenever 
necessaiy. 

Underlying the fdeset loc-ation database is a data replication 
subsystem that implements qnoiaun and voting algoritlims to 
maintain the consistency of fileset location data among all 
fileset location servers, even in the event of hardwcure or 
network faihu-e. A DFS client can thus get current ^ correct 
data from any fileset location server. 

DFS Token Management 

One of die major benefits offered hy DFS is its provision of 
smgle-site file system seu^antics. With respect to the file 
system, programs ninning on different machines behave in 
general -as though they are all mnning on the same machine. 
All clients see a consistent \iew of the file systen^t. If a pro- 
cess modifies a fde in any way, that change is immediately 
reflected in any operations performed on that file by other 
processes. To ensme this behaiior, each DFS sener host 
must know how clients are usuig its files. The DFS client 
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and sen, er pmc^ses exchange* this knowledge and sjnchro 
nize their actions by exchanging tokens. A token is a guaran- 
tee from a sen'er to a client, granting that cUenf permission 
to use a file from the sen-er in a particular way. Tokt^ns are 
handled by a DFB sub%^teni called the token manager, wlmh 
interacts closely i^ilh the cache manager on the dieiir side 
and the file exporter on the sen-er side. 

'nie rollD\*ing informatiun Ls encapsulated in a token: 

• Token Type. A bit mask thai encodes one or more of the 
values listeti in Table U. The token type describes tlie rights 
granted to a cheni by the token. 

• File ID, A unique low-le\'el name for a file. It consists of a 
DCE cell identifier, a DFS fileset identifier, a file identifier, 
and a version number. 

• Byte Rsmge. For data and lock token types, the byte range 
indicate the portion of the file to which the token applies, 

A DFS client cannot perform any operation on a file unless it 
possesses all the tokens required for that operation For 
example, the statf) system call requires a read status token, 
the readO syyten\ call retiLures both read status and read data 
tokens , and the open{| system call requires an open token. In 
some cases, the required token is afready being held and the 
operation can proceed immediately. However, in other cases 
the cUent machine must contact the token manager on the 
server host to obtain the necessary tokens. 

When the token manager on a DFS serv^er host receives a 
request for a token from a client, it first decides whether the 
requested token can be legally ^^r anted, based on a set of 
token compatibility niles. For example, several chents can 
have read-ciaia tokens for a file, but If one client has a wriie- 
data tokeji Tor a portioiv of a Qle. then no other client-s can 
have a read-data or wrile-dala loken that overlaps thai 
pctrtion. If the requested rtjken does nn\ conllict with iiny 
outstanding tokeas, il is granted immediately. Other"wise. the 
token manager first revokes any confiicfing hi kens from 
other clients before granting the reciuested token. 

The niies by whit^h tokens are expired, retunieil, or revoked 
are also import iuit fur correct semantics an(i optimal perfor- 
mance. A token has a firuie lileliitie, which a clieru can re- 
qtiest to extend if necessary. By defattll. tokens expire after 
two hours, which is short enough that a token usually will 
tune out l>eft)re the sener has to revoke ii. hut long eriotigli 
that the client usually will trot need \u retre^^h it. Daia*>r 
status tokens generally renmn with a dient until they either 
time out or are rev<7ked. Before retumntg a wiite token, of 
course, a client mast first send back to the seiTei' any modi- 
fications tliat it made to the file while it possessed the token. 

The file-vei-sion infomiation In a token lieli>s<^lienis use 
cached data erfieiently. When a client is gnuited a ttjkeii hy a 
server for a file that remains in its cache from a previous 
access, the client uses the fi I e-\^ersion infonna!ion to deter- 
mine whether the cached data ireetls to bt^ tjl^tained again. 

Conclusion 

The Distiibuted Computing Environment (DCE) integrates 
technologies for ilueads, remote procedure calls, security, 



Table II 
Token Types Used by the Token Manager 

Token Type Rights Granted to a Client 

Read Status Entitles a clieni to read the attributes of 

a file and cache them locally 

Write Status Entitles a client to modify^ the aiiributes 

of a file 

Read Data Entitles a client to read some portion of 

a file designated by an associate*! byte 
range and to cache it locally 

Write Data Endtles a client to modify some portion 

of a file designated by an associated 
byte range 

Read and Indicates that the client has an advlsoiy 

Write Lock lock on some portions of a file desig- 

nated by ait associated b,vte raivge 

Open Indicates tliat a process on that chent 

"~ ~ ' has a file open 

Delete Tecluiically a type of open token which 

is used during the deletion of files 

Witole Voiutne A special token that apphes to the file- 
Token set Bs a whole and is tised to coordinate 
the interaction between ordinaiy opera- 
tions on single Oles and operations on 
entire filesets, such as the movemetil of 
a fileset from one server to cin other 

naming, time synchronization, and remote file access. DCE 
eases the development and execution of secure client/serv-cr 
applicatioits and eiLsures the porlabilit>' and interoperability^^ 
of these applitrat ions across many kincis of <oniiJUters and 
r networks. 
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Adopting DCE Technology for 
Developing Client/Server Applications 

HP's information technology community has adopted DCE as the 
infrastructure for developing client/server information technology 
applications. The team developing the DCE service has discovered that 
putting an infrastructure like DCE in place in a legacy environment is fftuie 
than just technology and architecture. 

by Paul Lloyd aiid Samuel D, Hcirowitz 



Many compiiiiies ai'P na\igating the path tri op£?ii systems. 
Veiitlors, iiirluding HewU^rt-Packajd, daiin that txHii])aiues 
caji receiw* signiru^QTt bene tits by adr>]itmg open system 
client/seiver approaches for inipleriienting mfoniiatioii tech- 
nolog>' solutions. \Miile tlie beneHts may be attractive, the 
array of architecture and technolo^ ctioices is bewildering. 

Ilewlett-PackiiTfrs infonnation terhnolog^y gi'i>ui7 has ad( jpted 
the Open SofiwiU'e P^rmiidai ion's Distributed (Vaiipnlin^ 
Environment iOHF Dt'Ej as a recommended technology for 
the implementation of client/sender api>lic:ations withhi IIP. 
The adoption of a technology, or even an architecture, is not 
siifficieni in ensure dial thi^ benefits of the dient/.sei'ver 
mode] are r* 'a I i ^,e d . In fac t , m i v e I b e arc t li ( ec t ii re and t e< '1 1- 
nolog> are chosen, the real Jountey is Just ht^gijunag. This 
jiaper discusses the issues iltat. led UViu shif! toward open 
systems for infonnation tecluiolog^y client/server applit atioi^s, 
the rationale for choosing Dt'E as a key technology; and the 
elements of a new infrastJiictnre built to provide rhe neces- 
sary services requiied to realize tlie benefits of open systems. 

HP's Legaey Environment 

I 'Htil vpiy lerenily, HP's legacy environment mchided nnilti- 
pie mainframes and over 1000 tlP 3000 computers ojierating 
in more tiian 75 data centers located aroimd the world. 

Business ti'ansactioas were processed at places trailed sites, 
which were ma^jor HP installations including mamifac^turing. 
sales, ami atlmiihstrative renters. Each site lia<I a local HP 
3000 computer system. Most apj>lications were wriiten in 
COBOL and made extensi\ e use of HP's Tmbolmage data- 
base managenrent system and \Tlus/3000 routines for termi- 
nal screen iiuiuagement. These tools were used because 
they niatle the tnosi eOVcthe use of the HP 3000 computer 
system. At periodic Lntenals, batch jobs on the t!F 300(1 sys- 
tems would create transaction files fortransmissjoji to the 
mainframes. Other batch jobs processed files received from 
the 1 tia i i \ Ira i n e . A i>ix>p ri etaiy st ore-anci-f o rwaiil sy s te m 
provided die link between the interactive HP ^]t)OOs and the 
batcb-orieaied mainframes. Fig, 1 illustrates this legacy 
architecture. 

This architecture gave each site access to its own data, but 
only its owt\ data. Once a trarLsaclion w^as generated and 



sent to die niainframe, interaction with other profliict ion 
systems meant that response was indelenninate. For exam- 
ple, system users would ha\c^ tfi cheek repeatedly to deter- 
n\ine if a ]3urchase order that had been entered was ac- 
cepted by the factory and scheduled for production. This 
acknowledgment could lake from hours lo days dej>e ruling 
on the complexify of die order ajid ilie niimV)er of HP di\1- 
siojissuptilying content. In addition, processing ^tnci data 
conirminication delays anywhere in tlie company could 
impact tlte res]jonse time for die transactit>n. but the user 
liatl no way of finding rhe bnttleneck. Fuilher problems 
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were fourHJ dming nmssh-^ data center consolidations thai 
hav^e taken place over the past few yeais. 

The architecture for HP legacy applications >icMed a large 
number of applications, each of which required lai^e main- 
tenance and support staffs. Many applications were cu^oni- 
meii tei address ihi^ iK*culiarities of various sites. This eoiv 
tjitnitefi to the support problent As prucessing power and 
network bandwidtli grew, the customized versioas of stan- 
danl appIicaiioiLs made eonscjlidation difficult. In some 
cases, support costs actually grew. 

New applications were both expensive and took a long time 
to develop, in legate, and deploy. They made little use of 
previously written code, nor did rhey sliaie data or other 
resources effectively. Tltls resulted in a great deal of repli- 
cated data \^athin the company. As die en\1ronment contin- 
ued to evolve and new applicatioiis came online tc> address 
l^usiiieHS needs, users found tliemseh es ha\dng to manage a 
multitude of passwords for a large number of systenis. hYom 
a security standpoiJit, each password was transmit led 
__ mold 1)1 p times daily over the netw ork. and host -based login 
semces provided the foundation for all data security* 

Movement toward Change 

Several years ago, HP realized the benefits that could be 
achieved through oijen systems chent/serv-cr architectures. 
The singie l)iggest tiriver for the chimgc was a desire to re- 
duce business implementation time, wliich is the tune Trot 11 
when a business need is identified to the time when a pro- 
duction system is in place to address the n^i^d. Other drivers 
in' ludcd the nceil tor great <'r costHrlfectiveness of the hifor- 
nation technology (IT) organize it ion, MJid tJie need to reduce 
< perational and adtninistrative costs. An tnfonnation tech- 
nologic' steering grotii> determinet] that die wides|)read use 
of a t lienl/sen^tT aichitecture would enable a reduction in 
j/ business iinjtlcntcnialitjn time ;uicl tHtJvide increased organ i- 
zttt ion al ef fei t \\xn \ ess aJ n 1 reduce d ci >sts . 

A group of IT leadei-s represcnlinj* midliple HP organizations 
formed a task force to develot> a client/server architecture 
for use \vitliin IIP. Stmie of the factors the task force consid- 
ered vvlieu choosing I he best clicnt/stMver teclinology to 
adupl for our eiv\nn>mii(uit iuchidcd: 

• Training optimiziilion antl the experience of the cunenl 
staff 

• (Concurrent processing in a dlslnhiileil enWrontnent 

• Enhancing security for runndenfial ;uid t ritical data 

■ Moving application servers with niinlma] hnpact on chents 

• Providmg intenjperal nitty with exLsting cUent/sei'ver 
apphcations and tools 

• Enhancing the portability of at>pUcatjons across 
architectures 

• Operating across the HP internet on an enterprise-wide 
basis. 

The evaluation of tfiese factors by tlie task IVircc resulted in 
arec^ommendation tliat the Open Soft ware Ftnindation's 
Digtribulcd ('onifjiiiing Fjtvironmcnt he adopted asastaji- 
dard technology for flic imijlemcnialion of client/server 
apj locations within HP 



DCE and the Evaluation Factors 

DCE excels in the area of optiniizijig tiie training imcl exiieri- 
ence of the current staff. One problem faced by early adopt- 
ers of clieni/sen^er computing wbs that no one could agree 
on the definition of what was a cUent and what was a sen er. 
Tliis led to a plethora of home-grown and purchased solu- 
tions that did little to leverage the nature of the HP comput- 
ing environment. 

The fiefinitions of client and sem?r \\1tMn fX'E are c^orraistent 
and tangible, A client refers to a program that calls a remote 
procedure, A sen er refers to a program ti\at exetniies die 
procedure Tiiere is no confiLsion witii hardware or chents 
and sen ers on the same system or even a single program 
being both a client and sender. The definitions are entirely 
consistent, hr adtlidon, these definitions fit perfectly mtliin 
the context of HP*s client/sender application model. 

[)(.E uses the remote procedure call ( RPC) median ism for 
client/senTT conuuutii cation. This too is beneficial for pro- 
granmiers because it is an extension of a concept that every 
programmer knows and itndei"stands: ho%v to write mid exe- 
cute procedures (or subroutines). In DCE, RPCs behave the 
same as local procedures. They are still distinct, modular 
collections of functionality with well-defined parameters 
tfial behave in a "^black-box" fashion: send them the retiuired 
Ijmametei^^ and they reply in a predt^llned and t^'t'd Jdalile 
tnannen Fuillier, RPC is imobtnisive in that it 1 titles the cotn- 
plexit]? of Oie distributed en\ironmenL 

With RPC's, application progiammers do not need lo I earn 
the ititricracies of data networking or the particulars of a 
variety of application progranmiing interfaces (APIs) to 
implement distributed applications effectively- Unlike oilier 
teclmologies, RPC s ensure that the o])eratioiuil consider- 
ations of netw^ork jirogiiituming ate both hidden and aiitO' 
matic. Lastly, the DCE APIs requirefl to estaiilish the client/ 
seiver en\irt>nnient can be easily abstracted to hide eve^n 
more from the apjjiicatiott devclot>er with tlie furl her benefit 
of contributing to consistency in the euvJroiin^enl. 

ITsing these concepts, and the tools described later, severid 
of our a|)phcation teams have experienced reduced irni>le- 
merttation times in spite of tlie need for traininj^ in tH»w 
Iei*hnologies. 

New issues and opporttmities arise with the movement to 
chent/scner arcbilecliires. One of tliese opporiiinities is the 
ability to gain more effecdve use of computing resources on 
the network. Thi'ough the imijlementation of a threads facil- 
ity, DCE gives at>i)licaf itni developer-s the ability tf> liave a 
cUenl call mnltiijle seners simultaneously. In this way, an 
individual user executing a client program can invoke^ tlie 
parallel processitig power of many senf^i-s. On iJie other 
end, the threads teclmology also aUows servers to respond 
to multit>le clients by processing each request within its owti 
Ihrcad. Ibis eniails significantly less oveilicad thmi the cre- 
ation and desi ruction iirotcss cniployr^d by mimy aitemallve 
techiioiogifs dial ri'Ljuhc a unique sen er jirocess per client. 
DCE threads are briefly described in the aititrle on page (>. 
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DCE also incoiporares a tinte service API to pro^'lde a con- 
sislenl nctwork-witie view of time. This service addresses 
the issues created when appii cations require time stamps to 
be reconciled across geograpMc boundaries or between 
systems. 

Secunty is another aroa that raises hoth issues and opportu- 
nities. HP has tiadititjually used host password sec^urity imd 
the ser iirity features inherenl in tlie operating system to 
protect ciata and apijlicatioiis. Lf a user gained at- cess to an 
application, then the user was presumed to liave authority 
to t5Xfi*iite any ti ansae ii on perRjnoed by the application. In 
recent years, some application teams liave supplenienteti 
[lost security with features provided hy relational database 
rnajmgentent systetns (RDBMSj, but Uiese too aie usually 
limited in their flexibility For exatnple, a user that may have 
the ability to change a record when executing at) authorized 
transacthm should be proJilbited fn>tT^ doing so witlt a dala- 
base maintenance utility, Sucli discrimination is beyond the 
capability of most relational database maiuigement systems 
and rertuires added attention to system administration. 

DCE extends the concept of security to the appUcation it- 
self. The principles of DCE security are authentication anti 
auft\orization. DCE provides three senices lo enable the 
ultimate aut horization of actions within a server. The regis- 
try sei"vice is a database iLsed to keep infoniiation about 
usei:s, groups, systenis. and other jirincipals"^ that can have 
an identity ^'vitlun die DCE security frame W' or k. Tiie authen- 
tication service, based on tlie widely respected Kerberos 
teclmology from the Mtissachu setts Institute of Technology. 
iH usetl to allow principats to aiUhenticate themselves, llie 
jiiivilege seivice supplies die privilege attributes for a prin- 
ci|ial. Tliese attributes are used liy an access fontrol lis! 
( ACLj manager ^vithtn the body ofa seiver to make autho- 
rization decisions. Using an ACL manager, server autlioriza- 
tion decisions can be as gianulai' as busmess needs dictate. 
Back doors, such as maintenance utilities or rogue pro- 
grams, are^ not possil>Ic because usei^ have no access t<j the 
systems on which critical data is storetl. This makes the 
properly authenticated and authorized transaction the only 
vehicle hy winch a user can alTect the database. Security 
and ACLs aie also described in the articles on j)ages 41 and 
49, respectively. 

hi addition to authentication and authorization, r>CE pro- 
vides features to protect both the integrity ^u^d privacy of 
data transmitted over a network. Tliese features can t>e in- 
voked by chents or ser\'ers when the sensitivity of business 
data dictates that such precaut ions ^ire pnulent . 

Another challenge of the environment is change. Data cen- 
t el's are consolidated luid moved, and haichvaie within tlie 
centers is replaced on a regulm" bjisis. 

DCE provides a flexible, scalable direct oiy sei\ice that can 
be used to apply human readable names to objectjs such as 
sen-ers. Sen'ers rectird their binding information at startup, 
Client^s tlien locate senei^ \^ herever they may be. Multiple 
direct t^iy types penult great nexitulity for the apphca tion 
devclopen For exann>le, the corporate telephone directoiy 
may have replicated instances of the sender at matiy loca- 
tior^s. Shoidd one sender fail, a cheut cmi automatically bind 

A pnncipaE can be eito a liuman l/sbi m an active otDject j machine, ftfe, process, m ). 



to another. In the case of an online transactiori processing 
system, the one and only sen er cim be found reliably by a 
client even if it has been moved temporarily after a dis^Lster. 
Both of these cases can be accomplished with no changes to 
the client or the user's system coufiguration. DCE*s global 
tlirectory services sire (iescribed in the article on i>agp 23. 

Hewlett-Packard was a significant contributor to the tech- 
nology suite I hat makes up the OSF DCE defmition. C^ne of 
the most important conuibutioiis was the EPC mechanism* 

fiCE's RPC is a compatible superset of the Netw^ork Com 
puling System (NCS) from what was once Apollo Computer. 
The principles upon which the two solutions are based re- 
in ah i tlie same. Tliey include platform mdet>endence and 
platform unawareness. 

DCE platfortn independence conies from the fact that it runs 
on all c^iniputlng platforms in common use within HP's IT 
environment: HP 3000 computers, HP 9000 workstations, 
fntel-based Windows ' 3.1, and Wmdow^s NT Platfonn un- 
aw'areness cfinies from die fact that application program- 
mers only need to concern diemsehes with the platfonn 
they aie working on. Thus, w^hen a developer codes a client, 
there is no need for die developer to be concerned with 
what ]jlatform the server w ill run on. Conversely, the server 
developer doc*s not need to krujw what pialform the client is 
using. Thus, im application client nuuiing on a tlesktop PC 
can send a byte string or pointer to a server nmning on a 
PA'RISC platform even though the data representations on 
the two systems are different, F'ig. 2 shows a tyiilcal configu- 
ration of some of die components iti HP's DCE cllenUser\'er 
enviromnent. 

RPC provides the added betvellt of iiueroperating %vith clic ds 
and sen ers already implemented tising NCS. This provide, a 
transition for applications to the more robust world of DCE. 

HP operates one of Oie world s largest private Internet \ 

Protocol (IP) networks. The final criterion used by the task 
force was that the client^server technology' chosen must 
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opemte on HP s internet in an enterprise^wide fashion. DCE 
was designed to operate in the EP enwonment in a scale 
well above the size required for f IP's enterprise. 

The task force concluded that the adoption of DCE as a 

standard technology' would enable some significant benefits 
including: 

• Hefilacement of batch store-and-forward applicadons with 
CJLTP 

• Encapsulation of legacy rode and data into servers that can 
be accessed by GUI clients 

• InipJementation of cUent/serv^er applicatfons with minlraum 
training 

• Abstraction of much, if not all of tlie infrastructure so that 
appiicatioi^ teams can concentrate on the business aspects 
of applications 

• Lmplementation of enterprise- wide robust security 

• Mo\^ement of ser\ ers between systems \\ithout impacting 
the client or the configuration of the client's host system- 

BuiJding HP s DCE Infrastructure 

Becatise of the scope of DC E and the scale of problems that 
DCE addresses, careful planning is required wlien deciding 
how to deploy DCE. We found that the best approach is to 
start with the customers. ii\s a group responsible for deliver- 
ing DCE to IIPs LLifDrmalion !ectuu>logy cuinniunityt we 
defiiiPLl several t ategories of cystomers: 

• End users. These are the people whn intei'ac'tively use appli- 
cations, 

• Application development teams. These are the people re- 
sponsible for designing and constructing applications in 
response to some stated business need. 

• AppUcation ailministrators. These are tlie people who ad- 
minister and siif>port btisiness applications in production. 

Our group, which b the client/server tools group for HPs 
corix>mle network services depart nveiii. hm a long hisinr> 
of providing apijlicalion data transfer sol iii ions lo eacft of 
these tyjjes of customers. The lassoiiH gained frnrn tJiis ex- 
perience tU'e simple, even inl liit i\ e. End users wmit technol- 
ogy to be as absolutely invisibie as possible, application cie- 
velotHuent teams w^tnl to IVkus on their stu'cillr business 
problems. aJid ;ii)piit';:ilioi] ad iiiiiu.si minimi vVfint tools and sup- 
port. In other words, v^^hetu^ver users must rely on techitoJ- 
ogy to provide a solution, they want to be rcjnsumers of tlie 
teclnif>logy and Ukt^ all consnniei's, I hey tlematKl reHiun 
Ihings from a tet"hnolog> sii|i[»licr such as: 

• A higher level nf jtbst rail ion lluui is usuailj' provided by the 
technology 

• The al>ilily to make no< essary, simplilVing assumptions 

• A cofLsi.sleni level of service in all cases. 

Given these requirements, HP lias chf>sen to dei>loy DCE in 
the form of an infrastnic(ure. This infrasiniciiirt^ is knowit 
as the HP DCE st*mce. In corj^orate network services par- 
lance a service is an infjustnicture with some specific prop- 
edies. Tlie prime reason for the tent^ service is that the 
entire eflY^rl is rnciLsed upon meeting the net^ds (>(t)ur cus- 
tomers, tlie peoi>le of flewieti-PackartK The vvnn service has 
c<mnotatit>ns of c;m'hil i)lantung, staiuhu'dizatiori, putilished 
guittelines, and customer satisfaction. It does not have con- 
not ai ions of ( enrral control, eorptirafe niimdaie. or arlJitran- 
ness, Kinally, a sei-vice is a process as mii< li iLK it is a t-juigible 
solution, and it nn'Ognizes tlial as \\w snpiiislicalioH <jf its 



customers and their business problems grow wiih time, so 
too will their expectations. 

Associated with every service is a %^ue proposition. The 
\^ue proposition formally defmes the customers, the bene- 
fits provided to the customers, and the cost of these benefits. 

Our experience designing and constructing a DCE infra- 
structtire can t>e summarized very succinctly: 

• The infrastructure must ac*commodate diversity. 

• The utfiustrucrure must provide consistency. 

• The infrastmcture nuisf grow experience. 

Accommodating Diversity' 

Iden tiding diversity is a cnicial aspect of customer aw^arc^ 
ness. The custonu^i-s of a distributed computing solution 
come from aU piuts of the organization with distinct require- 
ments. We identified four categories that the DCE semce 
must accommodate. 

The first category^ is nenvork perfomiance, Cnsiomers of the 
DCE senice aie, by definition, usei-s of HP's IP network 
infrastrtitture. Because of differences in lietworking teelv 
nologi^', customers of the HP internet can realize a difference 
in both bandwidth anci transit delay exceeding two orders of 
magnitude. Given the re<iuesiyreply nature of the RPC proto- 
cols, this difference will also he reflected in everj^ DCE oper- 
ation. The leason of Qiis cattigor^- is tiiat the infrastructure 
must not make assumptions regai^ding the motion of 
paekets. 

The second category is application scope. Many business 
applications kire tnjly entert>rise-vi1de in scope in tliat there 
are lens of thousands of clients aiui massive, dviianuc repli- 
cation of tJie application servers. Many l->usuiess applications 
are only deployed to a single group or department where 
there are perhaps a few dozen clients and only a single ap- 
[ilication server is required. 

Tlie thu'd category' is the differenl lypes t if a|n plication usei-s. 
Sonu* iisei-s use data enlry^ ap])licatiofis in whirh a small 
number of Iransactions sire constajitly performed to add or 
modify data, Othei' usere use data cjiier>' applit rations to per- 
form a modest number tnmsactions to read data. Other ap- 
plit^ations provide decision-su|»[>on services, which topically 
allow users to peiff>nn ad lux transactions tiiat read data. 
Finally, some applic;ati<ms ser\'e noninterarfiye clients that 
t^iiicaUy invftke large numbers of transaclions that read, 
adiL and modify data. 

The fourth category is the geogmphic dispersal of Uie enter- 
prise. HP does business in sevei-al countries all over I lie 
wtirlfl. Miat this means is that nighttime or weekend service 
outages ranncjt bv tolerated* 

We learned from this khvd of analysis I hat f*nteq)rise"Wifle is 
a oni'-dimensional I emit iiJid re<il c»nteq)rises iire not one- 
tlimensionak We havt^ arided the tenus entertnise-deei) and 
enteiprise-broad. Ivtiterprise-<k>ep addresses tJie diversity of 
api>lit ation u.sers tiecanse it acknowletlges thai a successful 
iufnistnict urc* will accommodate eveiy type of user. Enter- 
]jrist^'lir(jacf addresses the diversity of ml work perrf)nnimce 
nnd ii])plication sropr l)y a( kuowkMigirig Hiat all business 
processing nnist In* acc<jmmoda(iML In ;nhIition, lorlay's 
business processes often t:russ cqmpiuiy boundaries. In 
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these situations, il a!sf» necessarj^ to hv entorjjme- 
inflepenfJent. 

liPs DCE ^emc'p a«^roiiitn(Hiatt*s rliversit.y in sevciral key 
ways. Tilt' [KjlJc'ies nml ^nnk'Vuw^ for the asfsignmrnl of reg- 
istry and namesjjace ( tX'Iv cell directory ser\1ce) f>bjecls 
j^upporl massive reijlicaiion of aiiplicaiion sen^ers. Tliis 
iillows DCE to be used as a foundatioji for imiy enlenjrise- 
vvide ('oir)puting> 71\e supijorl model spans ;ill organizations 
iuul all (jnte scones, ajul no cusIojiuts aie ever irealefi as 
second class. Tlxe subsenption niodel allows all customers 
to gain access r|uir-kly and easily. A subscri pi Ion- based ser- 
vice pro n ties convenient fucal points for s^ilistyiiix service 
n*qnr?^ts. F'initlly, policies and j^uidelines delegate rontrnl !o 
llu^ ajjpropriate level, ThiiH, sbice DCE is a distiibiiied etjui- 
piitin^ sol 11 don, its atiniirdstration must also be distributed. 

Consistency 

Pro\4ding cotisistency is a enicial aspect of customer satis- 
faction. Despite their diversity, all customers are consumers 
of the san)e t4K*hnolo^y 'nicy all deniimd a complete £md 
comprehensive solution. Pmlbermore. the biggest return on 
IT invest i!ient eujims frtJiu building on a consisteni founda- 
tion tliat encourages resource sltaring and leverages off 
other infrastructures. M in the case of diversity, th<^ bes! 
j>lacc to start is v^itli die customers. 

Find users have specific requirements regarding consistent y. 
Sint e (hey uvusf si( tu fn^nt of and interact with the applica- 
tions, enti usei^ ate best sent^cJ when all applications based 
on DCE offer a consistent itUerface witti respect, to D('E. A 
con sis rent intpifaf^e offers eciuivalent tlialo^i? boxes for per- 
fonning the standard tasks of DCE login ajui credent iai 
1 ef 1 esh . A c onsi st ent i n i e r f ac e al s o o f f e r s an 1 1 1 1 1 1 \ : j 1 1 m 1 1 
mecliiuiism of dialog bt)xes or conilguratlon files lor sener 
bindmg and serv^er rebindhig. Since DCE is an enabling lech- 
ntjltjgy. end users are ttest ser\^ed when they can access a 
vj;u1ety of DCE applieat ions using their unique, enteqirise- 
wide itlenriiy Gaining tivdemials should Ijc a side effect of 
being ;m employee of the orgatiixaiion. nol a side effect of 
bei!ig a user of application X. Finally tbere are standaiTl 
tasks, such as passworti athninisiraiion, thai all entI uset>5 
miLsl perform aiid 'dre Im^sI servetl when I bey all liave access 
t<i a sfimciai'd set of toots. 

Aj>]j Meat ion de\elopment leams have Sfiecific rettuiroments 
regarding tTjnsisiency. Simre apt>licxuion de\ elt)pnu^iu tejuns 
are responsible for uicot|>orating DCE fimctionality into 
appbcations as pai1 of a business solution, tbi^>' ;ue l>est 
sen c^d when they ctm make the necessai> sinifilifying as- 
snm[Uions. Application teanLs do not want the hurdtni of 
actjuinng ai^d administenng the core st^n-^ers tliat provide 
the DCE security senice and the DCE cell directory senice. 
Renio\ing tMs burden is esjiccialiy impoitant for tc^mis w ho 
de\ elop apphcations that nmst scale to ser\^e the entire 
enterprise. 

Ajiplication development tcmns also benefit from the abiHty 
to use tools that ahstx"iict die native DCE .'\PIs. Tliese loots 
dramatically reduce implementation time, and if they are 
-stantlard and consistent, training is leveragt^d aeross appli- 
cation team bomidaries as welt as across applieat ions. 



Finally, apj>lieation development teams benefit from the 
ability tt> leverage from estabUshcHl best (>ractices ami estab- 
hslied experts. Despite the ctjnunon mis<once|>tkHi Uiat best 
practices and expetts are an attempt to c^cMistrain teams, 
experience has sho^ii rheir advmitages, Cocie reuse and 
resource shai in^ improve because similarity can be lever- 
aged. Also, business implement an on time is less because the 
need for retraining is reduced, mul application quality 
increases bi^cause teants refine, improve, and reuse Oieir 
skills. 

Application adnunistralors have specific requirements re- 
giuding et)nsistt^ucy As is the case wirh a|iplica1if>n develop- 
ment tt^ams. adm i nisi rat ors are best served wlien they can 
make tJie necessiuy simiJiiryutgassumptitMS, If an end user 
ajiproaches the adtnitiistrator to gain access, the adiniitistra- 
tor shtuihl be aide to ;isk the tnul user's pnncitiiil name and 
then fit rCurm (be ai»i>n)i>iiate applit ation-s|>ecine At L ad- 
niinistratioii and grou[> nianagemt^nt. The nonapplic at ion- 
specific lasks of rettuesting aji eotl user principal and 
macliine pnntipal and obtaining i)rt>perly licensed copies of 
the DCE sf^ftwaie should i>e left tcj die ejul user. T\\e lienefil 
to the at)t>heaiion a<hiunistrator is vastly redueed wt)rki(jatl 
fjecause tJu« atlnhnistrattjr only deals witii die applit^ation. hi 
addititin, registt>^ olijects such as groups are leveraged 
across apjjlicarion boundaries, 

Apidicatior^ adntutist rat ons also benefit from tite ability to 
leverage the lies! fjraetices ajitl stamjaiij lools. If DCE a[)]jli- 
caticms use D( E olyects such as registiy gnHi[LS and nami^ 
space entries in a consistent fasliion, retraining is minimizefi 
and a lai^ge cause of administrative error's is reduced. 

Hewiett-I'ackard's DCE servlc e jiroviiies consistency in 
mimy ways. Cell boundary decisicnus are weighteti jt^ favor 
of larger' cells \u prtunote genuine enreiprise-vvide cornptU' 
ing. Tasks associated wUh DC E cell atlmrnLst ration have 
been abstracted into high-level tools based upon The ser- 
vices subscription model. Tliese tools automate and hide 
specific, low-level DCE tasks. For example, the task that 
corresj)ouds to an application subst ripbon creates piinci- 
paLs* groui>s, and act ounts ftn the ai>i>lications servt^ra, 
ci vales ntimesi>ac*e entries for the application, and nH>difies 
all associated access control lists. The btniefit of this 
abstraction is t lie consistency that it t^isiires Ijct auseihe 
actual registiy and nmnespace obit*cts are getierated and 
admuiistered in a siandaixi, documented manner. 

Growing Experience 

Growing exi>erience. w^hich means making both apphcatitin 
developers and a|>pIication users succ:essful, is a crucial 
aspect of realizing the busiiu^ss benefits of Dt E. Cleiuly. an 
uifrastnictm-e Uiat is not used is useless, throwing experience 
is a two-step process that ne\ er ends. Tlie first step is to 
iderUify barriers, and the setxind step is to remt>ve these 
barriers by miy UK^mis necessar>^ Such means mclude, but 
are not limited to, the development and deplo>Tnenl of cus- 
tom tools, ihe abstraction of DCE tasks to better suit exist- 
ing liusiness pracrices. mid expioitati<in tjf the fact that DCE 
is already one of its own best custonu^rs. The need for cus- 
tom tools is by no means a negative refiection on DCE, but 
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simply an afc*?ptance of the fact that no single solution can 

do evprythitig for e^'e^>'body- Abstraction is simply a way to 
make DCE fit the buisiness rather Utan forcing the business 
to fit DCE. Taking advantage of DCE means understanding 
that ev'enthijig in DCE is basically a DCE objeci acces^sed 
by a client rliron^i an interface and protein ed hy an ACL 

Application de% elopers face a \^ariet>' of barriers. The most 
traimiatic- barrier stems from the large number of new lech- 
nologies directed towards deielopnient teams. Keei^ tn mind 
tliat in most cjrganiaations, new technolog^^ really means 
new to the organization, hi Hewlett-Pac:kartK niosl IT a|Ji>li' 
cation teams are new to ii^Titing distributed applications 
using DCE's chent/ser\'er split or RPC paradigm. Our distrib- 
uted applications have traditionally been based on tile trans- 
fers or message passing. Tlie learning ciir\'e for ail of the 
fechnoiogies associated with DCE is non trivia!, espt^cially 
^\ lien Ihe ilevelopmeiit tools associated witli tlie teclinologies 
are still evolvttig, Ihe t^onsequence to iit)pllcation developei^ 
is that (Tearing tlie first DCE applicatinn wittt oui-of'the-hn^i 
DCE, even ax\ eval nation application. Is usually a iliffit nit 
task. The lisk is tJiat IT application teams will nor consider 
using DCE. 

Application developers also face barriers when testing or 
deploying applications. Tlie richness of DCE offers the de- 
velopers an oil en bewildering variety of choices such as 
different ways to take advantage of ihe tuniiespace or differ- 
ent niethocis of allocating registiy^ objects lo take advcinlage 
of DCEseciuity. Witliout guideliiies. established practices, 
and assistance some teams will simply try anything and tiien 
fail Reports of these failures usually travel faster aiid ^ider 
than reports of teams that succeed. 

HP's DCE service removes these bamers in three ke^ ways. 
First, the service provides a DCE develofjiuent library that 
abstracts the native DCE APIs h\t<t twr j very liigh-levfl A 1*1 
routines that include one call for the client and one call for 
the serV'Cr. Second, the senict^ off el's a custom version of 
the (JSFDCE progranuner's class, wliich rocnscs oti liF*s IT 
environmc^nt. Third, thf seti-ice offers consultants who c^ii\ 
help other entities start DC'E projects. A topical roiisttitirig 
venture involves the creation of hiterface Definition 
Langiiagt' (IDL) t fih's, a skeleton server that takes full 
advjLnta,L((^ (if stxurity anil the namespace, and a skeleton 
client tlial can hind to the server After tliis is all done the 
application team only has to add the application code 
between the curly braces. The best part of DC'E is that it 
allows, one Ifj flistribute an appUcation without w^oiTying 
aboil I how lo flo h. 

Application administrators face barriers because for DCE 
applications, there will be DCE related tasks that they must 
perform either directly or indirectly in a iiroiluctlon environ- 
ment. Although product it jn-c|uality DCE applications do no! 
require much attention, there are still issues tliat can arise. 
For example, tiiere is the occtisional athnh list rat ion of eml- 
poiiits and namespace entries in serv^er failure cases, the 
occasional adminislratitju of server keylab files, and most of 
all, the administtatioo oft lie application's AC Ls used to con- 
Trol authraizatiou. The rjut-of-tlieiiox DCE tools are cum her- 
some and error- tiroriej aiul worst of alL they are fairly low- 

f IDL is ij language simifar \u C that allows developers td specify the intBrfaces that tiediam 
and server applit&tmfis (ogethi^r 



level and require a fairly detailed icnow ledge of DCE con- 
cepts. Tlie risk is that DCE applications can acquire an im- 
deser%^ed reputation as being costly and difficult to support 
in production. 

HP's DCE service removes these barriers by pro\idiJig cus- 
tom OSF/Motif tools to ease these DCE related tasks. Also» 
the published guidelines and best practices diat bring con- 
sLsiemy tcj DCE appli< ations can help to grow experience 
by redticing ibe need lo retrain. 

System administrators face barriers because of the complex- 
ity of one of the most common lasks in a gro\^ing, maturing 
DCE (*ell. Since DCE regards each physical machine as a 
iniocipal with its o^ti aothenlicateii identity, configuration 
nnist l>e done on each macliiiie when adfluig il to tire cell. 
Tiie out-of-the-box tools lia\*e rwo significmit prablems. 
First, they require coorcOnation by the system admiiiistrator 
for root access. Second, if conriguratitjii is done acroj^s the 
network, both the root password and the DCE cell, admin 
password aie expensed. These are unat ce[>table secmity 
holes especially for a system tiiat is iutentled to ser\^e as a 
foundation for secm'e dLstributetl applications. In addition, 
many machines iilready run NCS applications, and these 
applications must not be imjj acted by the migration to DCE. 
As a result, installation and configuration are tedious and 
potentiiUly insecure, Tlie risk is that deploying DCE tluough- 
ou! the enten^rise will be viewed as slow and expensive. 

Hewlett-Packards DCE semce removes these barriers in 
three key w^ays. First, we have developed a scheme that 
allows a macliine to be remotely and securely added to a 
ceil In particular, this scheme does not expose the operat- 
ing sysletn or DCE passwords across the network. U also 
doesn't retjuire any effort on the part of the system admin is- 
Irairjr oilier than to insiall ati lirUX'f' fileseh Second, we are 
iiUcgratJng flic DC E clicnl software into a conunon ot>et;*t- 
h^g envitonment for machines that mn fhe IIF-HX operating 
system. Thiril we provide a PC-DC Ett license server to ease 
thiMliHtrihiJtiorKjfPC-DCM 

End users face a variety of potential barriers. Altiiough it is 
the job of tlie apt>licafi<m devch)tier to shield EjCE IVom end 
users, they will still he aware of tlieir Dt'E princif)al. Thus, 
end users should have miiumM training on obtaining and 
refreshing their netw ork crc^dentials as well as managing 
their [rrintipal. i J u to ft he-box DCE floes not includ*" a 
standaI(Jtie pass\\ ord nsanagemeni tool, and users nuist ac- 
tually run rgv_edit and mofiify their account. .\lso, integiated 
login solutions in which the operating system and DCE log- 
ins are c^jrnliinctl arc still evoKing (see llie article on tiage 
34), The risk is ihal dcijitiying DCE applieatlDns to Un-gv 
noniljers of end users can be slow, tedious, and expensive, 
and the end users who are exposed to too much DCE be- 
cause of poorly const nicted applications may assume that 
all DCE applicaiions are difficult to use. 

HP's DCE service removes these bariiers in two key ways. 
First, w^e provide tools on both the HP-UX operating system 
and the PC to ease password administration. Second, the 
servit es subscription model tn'o\Tdf^s a simple foca] jKiint 
lor re<iuesting tmd ohlaining a DCE print:it)al. 

TT PC -DCE is an rmpJememation ot DCE IM runs in in MS Widows enviTonmeni 
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Tlie final baiTier to growing experience comes from two 
gnnips of ]jeo|>le. The first group believes llial rlicnt/s^ener 
is really just remote SQL, and the second group beheves ttiat 
client/sender just means the motion of bits over the network. 
Remote SQL iw certainly a fine solution for^sutne business 
probiejns. However, it is inipoiliint to remeinix^r' that vejiclor 
Ififk-in, clienl-sitie awaieness of data t)ase schema, tielwtirk 
fjerfonnance on the WAN, and the usmd lack of network 
secLuity coidcl be problems in d eating witli remoie SQL. Al- 
though DC'E iloes move bits over the network, ant I other 
approaches sncii as message passing using sockets lukiy be 
an a<ieqnate solution for many business problems, the issues 
rif WAN t>erfonniince, architecture differences, code shaiing 
difficuhies, cofle maJnteuance difficulties, and the usual lack 
of netw(H'k security ccnild be prublems in otlier approa<:hes. 
Wlmn making technical decisions, hehig cioguvatic is usually 
the first step towards bemg unsuccessfiil. Tlie goal is not to 
dictiite or even to impress, but to educate and promote a 
community in which decisions are n^ade objectively. 

Hewlett-Packard's DCE service adcht»sses these barriers m 
two ways. I'lrst, we offer classes on all aspects of IK'E and 
its use- Second, senice subscribers can access all published 
infonnation using Worldwide Web browsers. 

Conclusion 

Perhaps the best way to get a cleai' pei-spective of HP's DCE 
senice is \ia analogy with other weil -known infmstnictmes. 
Consider custoniei's of a WAN. Everj'one wants acc*ess ^md a 
consistent sen ice mode! such as enten>rise-wide IP cf>nnec- 
tivity. Consider the lechnologi' tliat is used \o build a WAN. 
Now consider a successful WAiN infrastmcture, h is much 
more than the technology f i.e., routers, bridges, etc.) used to 
buihl it, it is a also a di.siributed creature ibat requires dis- 
tributed ad mi nisi ration ajui coord itiated plantiing aini guki- 
ance. Fuithermore, UTere is no distincUon Ijetween atest 
network and a production network. The netv^'ork is simply 
an infrastructure that supports all phases of die software 
lifecycle. 



Another valuable analogy is tiie inlerstate highway system in 
theL"nite(^ States. In the lihlOs automotive technology 
boomed and the resulting cost structures allow^ed niai\v 
people to own a car. This produced a fundamental (iiatige i!t 
American society becavise tjf the freedom, pow^ei\ and 
movemeni of goods and senires tlte automobile pemutted. 
Perhaps tlie biggest coiUrilmting factor was the mterstate 
highway system. The intent tat e highway system really 
wasn't: about automotive teclmology. It was about use and 
access. Distril>uted applications aie d\e same. The focus 
shonldji'i be on distributed computmg tecimology but on use 
and access. 

DCE is a powerful mid impressive collection of sothvare 
technology. It offers attractive solutions to the kinds of busi- 
ness problems that most huge orga[hzations must aridress. 
Otu" experience has demonstrated the following: 

• It is OK to exijerimenl. 

• It is inip^jriant lo allow^ a few key people to became 
indust rydevel experts. These are tJie people wlio should he 
resix>nsit>lc htr seivice uumagemenl. 

' DCE sluHild not be managed l^y regulatoiy pracfices. 
» IL is imperat ive to absti'act anything if the result better tits 
the business needs and business practices. 

• Action lies should not be done in secret or kept secret. 

• A sejvice sucit *is DCE is as much a contiiuial process as it 
is a tangible sohifion. 

Hf-UK 3.* and tO.O lor HP 9000 Series 700 and 80O CDmp4)ters are X/Open Company U^IX 93 
branded products, 

UNJX Is a rfigistBri^d trademark in the Unft^d States and tfttier countrt^, licensed exclusivety 
through X/Qtien Company I imited 

X/Open IS a registered frademart and tha X device is a tradenTark of X/Dpen Cwnpany Limrted 
ifi the UK aftd other nountfies 

Open Software Fountiatmn, OSf, and OSf/Mohf are trademarkij o1 the Open Software Foynda^ 
tjon in tha U.S. and other countrie? 

Windows and MS Windows are U.S registered irad&inarlts of Microsoft Corporation, 
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DCE Directory Services 

The DCE directory services provide access for applications and users to a 
federation of naming systems at the global enterprise, and application 
leveis. 

by Michael M> Kong aiid David Trtiong 



The direct or>' services of the C>ijen Software Foimdatlon's 
DLstjibiJie<l Computing Emlronment (DCE) enable distrib- 
uted appUratioiis to ase a variety of naming systenis, hoib 
within and outside a DCE cell Naming systents make it 
possible to gi\"e an object a texinaJ natne that Ls easier for 
humans to use — easier to read, pron ounce, tyyi^. remeniber 
and intiiit — than an identifier such as a DCE nnivei-sal unique 
identifier ( UtlDl, Infonnation about tlie locations of objects 
can be stored in naming s> stems so that users can access an 
object by nanie, wilh no a priori knowledge of its location. 

DCE provides three directoiy semces: 

• The Global Direct or>' Service (GDS) is the DCE implementa- 
tion of the CCITT (International Telegraph and Telephone 
Consultative Committee) 198S vX.5Q0 intemational standaid. 
GDS is a distributed, replicated director^' service thai niim- 
ages a global namespace for names anynvliere in the world, 

• The Cell Directory Service (CDS) is a distributed, replicated 
directory senlce that manages najiies within a DCE celL 

• The Global Directory Agent (GDA) is a daemon that uses 
global name services to help applications access nanies in 
remote cells. GDA interacts with either X.5O0 semces such 
as GDS or Internet Domain Name System (DNS) services 
such as tiic Bc^rkeley Inteniet Niuiie Dtjjumn (BIND) n^une 
server, named. 

Tluough tliese sendees, DCE applications cm} access several 
mtcrconnecied nmnespaces, inchiding X,50U, DNS, CDS, the 
DCE seciuity namespace (see article, page 41), and the DCE 
Distributed Rle Service ( fJFS) ftlespace (see article, page 6). 

The DCE Namespace 

Fhe DCK namespace is a federation of namespaces at diree 
levels: global narncspaces* im enterprise namespace, and 
applicatif>n namespaces, A DCE name iran span one, two, or 
all thret^ of titese levels. GDS aiid BL\1 ) rianu* servTis provide 
X.500 ajid DNS global namespat^es in which the names of 
DCE cells are stored. Within each DCE cell, CDS provides 
km enten>rise namespace, and the names of CDS objects in 
Ihat namespace are relathe to that cell. At the ai>plication 
hnel^ DCE subsystems including DCE security and DFS 
define their own namespaces, 

DCE names are hiermchical names t^onsisting of a series of 
cojuponents fielimitefi by the / ciiaracier Ti\e first component 
of a DCE name is one cjf three prefixes denotuig the root of 
a namespace: 

• / .- is tlie global rrjot. A name that begins with /.,. is called a 
globat ttame. 



• /.: is the rool of the local cell This prefix is shorthand for 
/..,/<loca3-cell-n3me>. Names that begin with /.: are called local 
mirtms. 

• /: is the root of the DPS filespace. This prelix, shorthand for 
/ /fs. makes DFS filenames easier to use. 

Within the local DCE cell, local and global names for an 
object are etjuivalent anti intercliangeable. However^ when a 
user references a local nante, the resolution of the name is 
relative to whatever cell the user is in. Hence, to access an 
object in a remote cell, a user must refer to the object by its 
global name. 

A D(^E cell has a global name that may be either an X.500 
name stored in GDS or a DNS i\ame stored in a BIND data- 
base. For example, a cell at HP's Cupertino site eoukl have 
the GDS global name /.../c^ys/o^hp/au^cupertino. hi X.500 syntax, 
the components of a name are separated l>y the / character, 
and each component desc ribcs an attribute of the object. 
The component o=hp, for insl:ance, signifies the organization 
named II R Tlie DNSglobiil name /.../cssl.ceJIch.hp.com might 
name a cell in ILI^'s Cheimsftird systems software ial> (CSSL). 
As 1 his example shows, a DNS name is a single component 
<jf a DCE name but is itself a compound name. DNS names 
ail? made up of names in the hieraretiical DNS namespace, 
separated by t>eriodsimd ordered right -to-left frtim the DNS 
root. 

Objects m a cell have names that are composed of the cell 
name, a (T)S name, and possibly a name from mi application 
namespace. Some objects, such as KPC senders, are named 
fUrectly in the CDS namespace; tlieir ntmies consist of a cell 
name ])his a CT)S name. Otiier objects, such as DFS files or 
DCE seeiuity principals, are managed Isy a service Ihiit hu- 
plements an application nmnespace. The name for such im 
object is formed by concatenating a cell name, a CDS name 
for the rool of tlie at^plication nmnespace, and an applica- 
tion name relative to that root. For example: 

• If the HP Chelmsford systems soft wme lal) cell is nuuting 
an RFC server from tlie Acme Database tl'oinpanj^ that 
server might be registered under the name /.../cssl.cellcti.hpxofTV 
aCFne/acme_server (see Fig. I ). Within tiie CSSL cell^ /.:/acme/ 
acme^server would be an tH|uiv;ilent name for the seiner 

• If the HP CSSL cell inclndes a principal named Nijinsky. that 
principal wonld have the global name/., /cssi celLch.hpxom/ 
sec/principal/nfjinlcsy (see Fig. 2) and the local name /,;/sec/pfirci- 
paVmiinksy. 

• If the fJFS filespace in the HP Cupertino cell contains a file 
called /users/sergey/matl/igor, that file would have the global 
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/, , , /E3U9;/Q3hp/pu=cuppnmi]/f^uB£rs/5srgBr/mftil^gor 



Global Cetl 

Name 

linDNSf 



Server 

Name 

(in CDS] 



Glottal Oil j eel Name 
Fig. 1 . A DCE globai naBic-- fctr a sener. 

name/.../c=Lis/a=hp/ou=cLipertino/fs/users/sergevMaf1/igor (see 
Pig. S). Wiikiii tlip ("upiTtino rvU. I he naiiies/.:/fs/users/sergev/ 
mail/igor aiid /:/users/sergev/mail/igor would be equivaipm names 
for the file. 

Directory Service Interfaces 

DCE offers two sets of prograniniin^ inlciiiices lo clirector>' 
senices. The RFC Name Semce IndepeiideiU (NSI) API iy a 
generie naming interface iiravideti by t)CE IIPC. Tlie X/Open'^ 
Dn"ect.or>^ Senice (XDS) um\ X/Open OSI Abstiait Data 
Manipulaiion (XOM) APIs ai*e hiterfai^'es based on CGITF 
X.500 standards. 

Transparently to mi apjiUcation, the DCE director^^ services 
inicrael with each otlier as necessaiy to resolve n^unes, 
Fi^, 4 ilhistmles some of the inten-elationships between 
these services. 

UTien a DCE application [lasses a name to the RPC NSI API, 
CDS cUent softwEue {in the DCE mn-time libraiy and in CDS 
client daemons) uses E>CE RPC to contact a CDS sener 
either in the local cell or in a remote cell lo look up the name. 
Names in the local cell are passed directly to a CDS sener 
hi the celL Names iita remote cell are iia-ssed lo a (il)A dae- 
mon, w'hich perlormi? a lookup in X.5()0 or DMS, depending 
on the syntax of the cell name, to obtain the location ajid 
identit>^ of a CDS sender in tlie remote cell. The CDS client 
software then uses tins infomiation to contact Uie remote 
CDS serv^er. 

Wlien an apphearion passes a name to the XDS/XOM APLs^ 
the XDS code in the DCE nin-time tibraiy resolves the name 
acrcording to its syntax. If the name consists purely of com- 
ponents snch as c=us and o^hp, the XDS librai^^ passes the 
name to the CDS clietit code, which contacts the GDS server 
to look up the name. If any portion of tlie name is tiot in 
GDS s^nitax, rhe name is passed lo the C US client code and 
resolved in the same way as names passed through the RPC 
NSI APL 

GDS Direct orj^ Structure 

The GDS dheclojy Ls a collection of hvfonnation alioul ob- 
jects that exLsi in the world, hifomialion about objecti? is 
stored in a database called a di rectory informal ion base. A 
directory information base contains an entry tlial completely 

/. . .^CSS^.celLhp.cDin/sec/principal/nijiiiskv 
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Name 

(in DNS] 

Name of 
Securriy Root 
(in CDS} -^ 
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Global Obje€i Name 

Fig, 2. A UV.K jijlobal name for a principal. 



GloliHt Cell Name 
(inX.5O0) 

Name at DPS 
RijoMmCDS) — 



File Name 
{inDFSI 



Global Qbioct Name 
Fig. :i. A DCE giobd name for a file. 

describes each object and may also contahi an alias entryf 
that provi<Jes m\ altematise nai iie foj tin object entx'y. 

^\n entiy in the directoiy inforinatiort base consists of a set 
ot attributes, each of which stores information about the 
object Lo which the entry refers. An artribute is niade up of 
an attribute type iuid one or more attnl>ule values. For ex- 
ample, an entry for a persort might include attrit>utes whose 
attiibute types are surname^ common uame, postal adciiess, 
ami t.eleph<:)ne nujnber Arrrihutes that have more than one 
value me called multivalued attributes. A person with more 
than or^e telephone nmnber would ha^^e a multivalued tele- 
phone number attnbute. 

Each entry can belong to one or more object classes. .An 
object class of an entry restricts the permitted attributes for 
that entry The mandatory and optional attributes of entries 
in aii object class are determined by object class niles, and 
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Fig. 4. Interrelationships betv^'een DCE direetory services. The 
appliLiitioii program interfaces (APIs) are tht^ DCE remote ijroce- 
dure catl uame senice independent Af'l (RPC HSI API) and the X/ 
Open Dirertoiy Service (XDS) and X/Open OSI Abstmr-T Data Manip- 
ulation (XOM) .^Is. GDS is Lhe DCE Global Direcion^ Semce and 
GDS is the DCE Cell EJirectury Semc.e. CJDA is the DGE Global Di- 
rectcfrj^ Agent. X.500 is an international staiidard invplemented by 
the DCE GDS. DNS is the Intemel Domain Name System. Tlie Berke- 
ley Internet Name Domain rBlND) is an iin|.ilemeniatlon of DNS. 
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these rules are part of a schema For esample, an entry rep- 
resenting an organization must contain an attribute called 
Organisation-Name* which has the name of the organization as 
its value. An enu>' can contain optional attribtiies iliat de- 
scribe tlie organizadon: the state or locality in which the 
organization resides, tlie poscal address of the organization, 
and so on. As a general mle. all enirses must coniain the 
Object Class attribule, which f on tains tlie list of object clasKe?^ 
to which the entry belongs. If an entry belongs to more than 
one object class, all object classes must be listed in tills 
attribute. 

As discussed above, attribute t>pes and object classes have 
human-readable names tirat aie meaningful and unique. Ijut 
they are not iLsed in the protocols; an object identifier is 
used instead An object identifier is a hierarchical number 
assign e<i by a registration authority. Tlie possible values of 
object identUiei-H are defined in a tree, llie standards com- 
mittees ISO and CCITT <^ontrol tlie top of the tree and define 
Ijoitions of tliis tree. These stajulimls committees delegate 
the remaining portions to other organizations so that each 
object class, attribute type, and attribute s^TitiLx has a unitiue 
object identilier For example, the object identifier of the 
country object class Is 2.5.6.2, which can also be wTitleti more 
verbosely as; 

iomt-iso-cdtt{2}modLiles{5}Dbiect c lassesie}coLniry|2}. 

X.500 Naming Concepts 

Infoimation in the directoi>^ infonnation btise is organized in 
a hierarchical structure called a directory information tree* 
A hienu'chical i)atlt called 'ddLslingtiished Nfjtttf, exists 
from the tool of the tree 10 any entry in the directory infor- 
mation ba-se. f^ach entrv in the direct o^>^infu^nal 14 in base 
must have a mune that uniquely dcscrilies titat entr>'. For 
example, the employee (entry) IJavid has the distitiguished 



name C=LlS/0=hp/OU=h|HncyCN-08virf, vphere C denotes the cotm- 
tr>'. the organization. Otl the organization unit and CH the 
conmion name. 

Tlie tiistinguished name is a collection of attribute type and 
attribute value pairs called relative distiiiffuished names. 
From the example above, C (country ) is an attribute type 
and US (United States) is an attribule value. 

.^iemati\ e names are supported in the directory' information 
tree through special entries called alias entries. An alias 
entiy is a leaf entrv' in the directoiy^ information tree tliat 
points to anotlier name. Alias entries do not cotttaiti any 
attribuies other than their dislinguishe<i attributes because 
they have no subordinate entries. 

GDS Components 

As shown in Fig. 5, GDS is made up of four main com- 
ponents: 

• Director>^ I'ser Agent (DUA). Tliis process is the users 
repjesentative to the direct Qr>- senice. Tlie liser can be a 
person or an appUcation. 

• Diiectoi^' System Agent (DSA), This process controls and 
manages access to dii*ef;lor>' information. 

• DUA Cache. This process keeps a cache of information 
obtained from 1 lie directory DSAs, One DlIA cache runs on 
each client machine mu\ is used by aU the users on diat 
rnacliine. The fJl ' A cache contains copies of recently 
accessed object entiles and infoittialion about DSAs. 

• Director>^ hifonnation Base, This is wiiere GDS stores 
infonnation. 

Tlie DUA and DSA commimicate by using tJie director>^ 
access prorocol. DSAs use the directory system protocol 10 
conitnutiicate widi each <jther. 
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Smce director^' iiifonnatioji is distributed over several 
DSAs. a DUA first (lirpcls any (lueries to a specific DSA. If 
Uiis DSA does not have the inromiatmn, there ai'e two sian- 
daid request inetJiods that iJie DUA can use. The first metiiod 
is refeiral — the DSA addressed returns the Queiy to the DUA 
together wii h a j^eference iudicating the other DSAs that 
have I lie infonuation, Uliairiing \si\w second request 
method^the addressed D^SA passes ou the query cihectly to 
another DSA via the directory system protocol. 

CDS Directory Structure 

Every DCE ceiJ Jiuist have at legist one I'DS sender. The CDS 
servet^ in a cell eollecfively maintain a cell namespace, or- 
ganized into a hierarcliieal rlireruiry stOK-ture. As nientior^ed 
ahove, tlie prefix /.: is sh on hand for the gUihdi name of the 
cell and hence denotes the root of the cell namespace, 

A CDS name is simply a series of directory nanies followed 
by ati entry name. The direetorj- names are ordered I eft-to- 
ri ght from the ceU root and are separatt^d hy tlie / character. 
For example, in the name /.;/3cme/acme_server, the chrectory 
acme is a child of the cell root and the object acme_server is an 
entJ7 in acme. 

In a ceU that contains more than one CDS server, CDS direc- 
tories can be replicated, with each rephca of a directory 
managed by a tlifferent CDS sender Among tiie replicas in a 
set, only one. the master rephca. is modifiable; all other rep- 
licas are read-only. Replication increttses the avtiilability and 
rehabihty of CDS service and can ^ase recovery from hard- 
ware or network farlm^e, 

A CDS directory can contain three types of entries: 

• Object entries c-ontain inforntation about objects in the cell. 
An object can be a iiosi, a user^ a server, a tievice, or imy 
Other resource that has a CDS iiau\e, 

• Soft litiks pro\dde alternate names tor object.s, direct ones, 
or other' soft hnks. 

• Cliild pointer's are pointers to the directories contained by a 
parent du ector>': A clrild pointer is created when a now direc- 
tory is created and is uscil by CDS to locate replicas of that 
dij'ectoiy when resolving the directory's name. CMld pouiters 
aie created only by CDS itself, not l>y applications. 

Like GDS, CDS stores inforTnation about named objects by 
associating at tnbutes with names, Object entries might have 
attributes to store the objects UUID, its lof atiun, hs access 
control list (ACL), the time it was created, and tlie time it 
was last updated. A soft link has an atrribuie to store the 
name of the object to which the link points. 

Two special classes of CDS object entries warrant particular 
mention: 

• RFC server entries store infonnation about servers, including 
their locarion and the objects they manage, in the CDS data- 
base. Ser\'ers register this binding uifonnation, and clients 
look it up, via the RPC NSl hrterface. 

• Junctions enable a sendee that implements its ovm name- 
space to splice that nanrespace into the DCE namespace, A 
jimctiori is somewhat ajialogons to a tnourit point in a 
i^MX file system; tlie j miction entry stores binding uifor- 
mation for a service aird becomes the root for the name- 
space nimiaged by that semce. The CDS entry /.: /sec. for 
example, is the junction for the DCE security senice. Appli- 
cations can use names such as /.:/sec/principgl/stravinsl(y to 



identify principals in the security registry and to obtain 
bindings to a sertirity sender. Similarly /,:/fs is the junction 
for DFS, and/.:/host3/<host-nanie>/config is the junction for the 
configm'ation sendees provided on each host by the DCE 
host tlaemon, dcsd. 

CDS Components 

CDS is a distrlbiUed service based on a client -server model. 
Fig. 6 illustrates the software conrponents that implement 
this service. 

All CDS dh etMory data is stored in databases called dmnng- 
housPH. which are nianaged by CDS server daemons. The 
ser";. er daemon responds to requests from CDS clients for 
loolarps in or updates to the database. Wlren an RP(.' server 
invokes an RPC NSI API routine to export binding inforTira- 
tion to the namespace, ff>r example, tfus routine triggers a 
CDS update operation. Similarly, when an RPC client im- 
ports bindings from die nanrespace, a CDS lookup operation 
is executed. Each €'DS sender keeps an image of its clearing- 
house m memory and writes the cleaiingliouse periodically 
to disk. 

A cell often includes more tlrarr one CDS serv^er, each with 
its own clearinghouse. Runniirg several CDS server's in one 
cell allows administrators to repUcate CDS directories. K a 
directory is rep heated, one clearinghoiLse stores the master 
replica of the directory, and other clearmghouses store read- 
orTly rei.ilicas. Clients can perfbnn looku])s fronr any rephca 
biU can perform updates only to the master replica. Altera 
CDS entry is updated in the master replica of its dlrectoiy, 
the CDS server that manages the nraster rephca pr opagates 
the update 10 irll ( DS seiver"s that manage read-only rf'|jlicas. 
Replication improves responsiveness to clients by distribut- 
ing w^ork among several ser'v^ers aird ensures the availabihty 
of CDS service if a ser\^er machine fails or the network fails. 

The architecture of CDS insirlates apphcations from direct 
commimi cation with CDS servers. To add, delete, or modify 
CDS data, applications call ^\PIs such as the RPC NSl rou- 
tines hi the DCE rTin-timc libr^y. CDS client code in the 
library iitieracts with a daemoir on the local host called the 
CDS advertisen which uses RPC to comnumicate as neces- 
sary with CDS sen-ers. A CDS advertiser nms on eveiy host 
irra DCE cell, (In many DCE implementatior^s, several C.DS 
chent daemons execute on each host: one CDS advertiser 
aird a nrmiber of CDS clerks. In the IIP DCE/9000 product, a 



Ctiant HdsI 



Applku lions 



CDS 
Ctjeni Ubt^fy 



CDS SfifV^r Host 




CDS Server Host 




Fig. 6. Ce-u Director' Service (CDS) components. 



26 



Docembpr 1995Ttewlett-PackarfJ Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



single CDS advertiser process subsumes all advertiser and 
clerk tasks.) To increase client performance, reduce server 
load, and reduce network traffic, each advertiser saves the 
results of its lookups in a cache. Frequently accessed data 
can be retrieved locally hroni the c^ehe rather than v\b RPC 
from a server. The ad\-ertiser writes the cache to disk peri- 
odically, so cached data persists ihrough reboots of the CDS 
client host. 

Conclusion 

DCE provides a three^]e\^el naniing system and two naming 
APIs. 

Names of cells are stored in a global namespace managed by 
a DNS serv^er such as rtamBri or by an X.5O0 server such as 
the DCE Global Director>^ Service (GDS). The Global Direc^ 
torj^ Agent (GDA) oversees resolution of global cell names. 

Tiw cell namespace consists of I wo levels; the enteri>rise 
namespace niarmgetl liy the DC E Cell Directory Service 
(CDS ) and application namespaces such as those managed 
by DCE security and the DCE Distributed File Senice 
fDFS)* The roots of application namespaces me named by 
CDS junctions. 

DCE offers two natning APIs. The RPC NSI interface is used 
by ser\ ers to register their names atid locations in CEjS and 
by clients to look up niunes and get back binding informa- 
tion* The XDS/XOM API can access names and theu" associ- 
ated attributes in GDS and CDS. 



Hie DCE name services have some limitations that X/Open s 
Fedemied Naming sp€?ciBcation attempts to solve (see 
article, page 28). The RPC NSI API is a specialized interface 
that manages only RPC binding handle infommrion; it can- 
not read or nianipulate other attributes associated with a 
name. Many programmers find the XDS/XOM .API cumber- 
some: this interface is also difficult lo layer ov^er odier exist - 
ing naming APIs. The RPC NSI API and ihe XDS'XOM API 
do not offer a way to create or delete direciories progmin- 
matically, so an application that needs to create directories 
currently must use an internal CDS il^^e^rat^e. The CEJSand 
GDS i>rf>to(^ols are complicated and not very generals New 
naming senices that are introduced are unlikely to use 
either of tliese protocols or tlie XDS API. Finally. CDS does 
not support an easy, general way to create and resolve 
Ihrough junctions to application namespaces. 
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X/Open Federated Naming 

the X/Open Federated Naming (XFNt specification defines uniform 
naming interfaces for accessing a variety of naming systems, XFN 
specifies a syntax for composite names, which are names that span 
multiple naming systems, and provides operations to join existing naming 
systems together into a relatively seamless naming federation. 

by Elizabeth A. MartLii 



Naming of objects is a funi^liiSii^^llal need in a coniputiiig 
sysrem. A Tiaiuing senlce maps Tiunian-readable naines to 
internai location inronuaiion that programs use to access 
the named objects. CiuTCnt tUstribiited comiJiitrng enviion- 
ments lltat take ad\ antage ol' large computer networks pre- 
sent new problems and requirements for the naming service. 

Heterogeneous niuning systems are a reality. Unlike the 
namuig service in a single-host system, the naniuig service 
in a distributed system is usnaily not a monolithic compo- 
nent but consists of various naming .systems cmbetlded in 
different pieces of i he system. The naming systems in the 
Open Soft^v^are Foundation (OSF) Distributed Computing 
En\iromnent (DCE. see article, page G) include the X.500 
director^' service,^ the DCE CeU Director>' Senice (CDS)r 
and the DCE Distributed File System (DFS, see page 6), The 
DCE security sendee (see article, page 41) and the DCE ciae- 
nton (see arlicle, i>age 6) also support nantespaces. A tyijical 
DCE iiistallatloji will have apf^h rat ions that havetlieir own 
naming systems, such as databases, email, desktops, and 
spreadsheets. 

These different naming sy stents liave arisen in pait because 
tliey meet different reriiurenients. The DCE serurity seiver 
uses special and somew'hat inconvenient measures to pro- 
teti^t the keys of princii>als in the system. DCE CDS directo- 
ries arc rephcated but a desktop is not. A spreadsheet 
names fine-grained objects [its cells) which present unique 
scaling problems. Nev\- naming systems will contimie to 
appear, particularly in applications. 

Up lo now, there has been no btisic and consistent naming 
inteiface. Each najning sysleju h^is its own API^ so applica- 
tion progi^nmei^ niusi write custom software for each 
naming system that fhelr a]>plirations use. Wl\en applica- 
tions are ported to different systems, they must be modified 
to use tiiat systems mmiing interfaces. As new naming sys- 
tems are irnro<hiced, applications that need to use them 
must be extended. 

There has also been no first-class, generic support for com- 
posite names. A few distributed systems support composite 
names — names that span multiple nammg systems. This 
support is limited and specialized. The DCE name 
A^/ch.hp.com/sec/prmcipaJ/jsmiih is a composite mmie, ch.lip.com is 
resoh^ed in the Internet DNS'^'^ namespace, sec is resolved in 
the DCE CDS namespace, and principal/ismiih is resolved in 
the secLuity senice s namespace. In DCE only the security, 
file system, iuifi DCE daemon namespaces can be accessed 



througli composite nan\es, UNIX® rep uses composite names 
in a diO'ereni way fron^ DCE, For example, aiaxi/usr/jsiriith/nam- 
jng/memo.txt is an rcp uame with two components: ajax is a 
host najue and /usr/jsmith/narning/menio.txt names a file on ajax. 
IJCE aitd rcp use their n\vn s>Tttaxes atid conventions for 
tJieir names. 

Another area of inconsistency between naming systems is 
their polieies for^ lu>w the namespace is stiTictmed. Many 
system^) tmve veiy little jioliry and what policy there is has 
evolved in a hajjhaziucl way. Apph cation writers who use tlie 
naniesjiace to advertise their seniccs must ff>ll<j w different 
conventions for the \'arious en\irotnnent^ in whicfi their 
prf>granis will niu or they nnist. invein their own policies for 
using the iiauTespace. Administrators who eontlgine a she 
are also faced with confushigi inconsistent, or no policy for 
how to use the najnespace. End users need intuitive ways of 
finiiing atid naitung (jbjects. 

Overview of X/Open Federated Naming (XFN) 

Several vendors of distributed computing systems realized 
that they shared these naming problems. Engineers from 
Digital, HR IBM, OSF, SNC and Smisoft started work on a 
naming specification hi June 1903. hi March 1991 version 1 
of the Federated Nmnuig Specification ' went to X/Open - for 
fast-track re\iew. The specification achieved preliminaiy 
status in July 1994. Tlu^ nmltivendor team continued to wtirk 
on extensions to die specilu-ation and (jn validating it 1 before 
it became part of the X/Open Common Application Emiron- 
ment (CAE) hi 1995. 

The XFT^ specification riefines application programming 
interfaces (APIs) and corresponding remote procedure call 
(RFC) interfaces. XFN specifies a jiaming syntax for com- 
posite names and provides operatirjns to Join different nam- 
ing systems together into a relatively seamless naming fed- 
eration. XFN also specifies some naming ]>olicy. 

Fig. 1 illustrates an XFN configuration. The XFK AJ't is lay- 
ered over a "framework into which different context imple- 
mentations aie inserted. A specific context ijnple mental ion 
is required for each naming system in a federal it:>n. A am- 
lext implementation maps XFN operations into otJerations 
that are native to its ntunhig system. Foi' example, ihe N!S-h*'^ 
c<:intext implementation maps operations hi the XFN API to 
correspoiitling operations hi the NIS-s- AI^L A namuig system's 
software below the context implementation is not ehariged. 
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To join a federation, a naniirLg system must siinpiy provide 
its specific context implementation. 

lit Hg. I the client-side softvt'are for five natning systems 
runs on tJie XFN client system. In addition, an XFN client 
module that imp oils an XFN proroccil is on tliis system. Hie 
XFN client tnodule may do cacliing and other t>^)it*;Ll tiamuig 
client jobs. Each naming client on the system uses its native 
protocol to conmnmicate with its server. 

Deriultions 

hi this section and hereafter in this ailicle, panignitths in 
quoiatitjn marks are taken directly from the X/Open Feder- 
ated Nanting Sj^eciiKvition."* 

**Every name is generaie<l by a set of syntactic niles called a 
naminfi coiwmilmn. Ari ntomlv immf is an iTulivisiijIe com- 
ponent of a name, as definet] Ijy \\w naniir^g cimveni ion. 
A fompoumi nnmf represents a seiiuence of one or more 
atomic names coiriposed according to the rKuning tninven- 
tion.'* 

Case sensitivity^ the choice of escape, quote» and delimiter 
characters, and the order of atomic names in a compoimd 
name are t*otnnK,)n feat tires of a naming converttioti 

'*In UNIX pathnames, atomic names are ordered left to right, 
and are delimited by slash (/) chaiacters. Tlie UNIX path- 
name usr/local/bin is a compound rvanu* representing the se- 
quence of atomic names, usr, locat, and bm. In names from the 
Intertiei DNS, alotnic names are ordererl from right to left, 
and are delimited hy (!<jt (.) characters. Thus. Ihe Ij.\.S name 
sales-Wiz.cam is a nmipound natne representing the sequence 
of atomic names com, Wiz, sales." 

"The mfrrtmee of an object contains otie or more communi- 
cation endpoitits (addresses). The association of an atomic 
name witli im object reference is calleti a binding. A contej't 
is an ijl>jecl whose state is a set of bi tidings. Every context 
hjts an iissociated naming convention." 



A UNIX directory is a tj^e of context, Aji atomic name in 
one context can be boimd lo a reference to another naming 
context object, called a suhconteM. 

"A naming systnn is a connected set of contexts of the 
same tv^je (ha\ing the same naming cotivetitioii) ^md provid- 
ing the same set of operations with itientieal semantics. In 
the UNIX operating system, for example, the set t:jf directo- 
ries in a given fde system (and the namitig operations on 
directories) eonslltate a naming system. A mnniug sennce 
is the service offerecJ l)y a naming systetn. It is accessed 
usii^g its interface, A iHime^^pare is the set of all names in a 
naming system." 

The XFN API 

XFN defines uttiform naming interfaces that support, basic 
naming functionality. As illustrated in Fig. 1, the XP'N inter- 
face is layered over specific naming services* APIs. The de- 
tails of the undei lying naming system are hifkien from the 
apiJJication. Apjilications that use the XFN API can access a 
vaiieiy of cuirent and tiiture naming sy stents without 
modification. 

The operations in the XFN interface range from simple to 
com|)lex. Simple naming systems are not exp(*cted to strt>- 
poi1 the more comphcated operations, but the timctionality 
offered by soj)histicatefi naming systems (*an stiil be accessed 
%ia the XFN API 

The XFN base context interface includes operations to bind 
Ml atomic name in a context to an XFN reference and to 
unbind a nanu*. Other operations iti the XFN base context 
interface louk uij a name imd return its referent^e, look up a 
link, list all names and bmdings in a context, and create a 
subciintext. 

XFN supports the itoiion of aitrii)utes (or t^'opeities) assfjci- 
ale<i with a name. Attributes can l>e used to provide sumitiaty 
rhar^ict eristics about the object being tiamed. For exam|>le. 
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a pdiiter might be named y..^Wfzxom/eng/os/service /prntrl . Tiie 
name prntn woulri be hoiuid to an XFN j'efererice ihat con- 
tatns the address of the ser\'er for that printer. Attributes 
could also be associated with the name prntr) that describe 
its tyi^e (LaserJet, inKjei, etc J and the formats it supports. 

Attnbutes are accessed through the XFN attribute interface, 
which includes operatic jils to set, modify, and get attributes 
associated wjUi a name m a context. An attribute eonsist-s of 
an identifier, a syntax, and one or more values. Operations 
to search for names whose attribute values n Latch a filter 
expression are also defmed. hi the piinter example, a search 
operation could be used to locate a LaserJet printer in the 
eng/os deparlmeni that supports the PostScripts^* fonnat. 

The XFN API has been mapped to Internet DNS, CC'ITT 
X,500, DCE CDS, and ONC N1S+. Smce X.5O0 provides the 
most functionabty of these naming s>'stems tlirough its XDS/ 
XOM AP[. this naming system presented the most challenges 
for XFN. XFN captures the functionality of XDS/XOM but is 
a simpler, more intuitive API. 

Support for Composite Names 

XFN specifies a syntax and [jaisirig nlles ff*r eomj>osite 

names. Operations to manit^ulate Uiese names are also 

provided. 

**A rompo.'iffp naiitp consists of an orflered list of zero or 
more components- Each component is a st r ing name from 
the namespace of a single naming system and uses the nam- 
mg syntax of that naming system. A component may be an 
atomic name or a compomid name from that namespace.'' 
The string form of a composite name is "the concatenation 
of the components from left-to-right with the XFN compo- 
nent separator (/) between each component/' 

In the DCE composite name /.../ch.hpxom/sec/pnncipal/jsmiili 
mentioned earlier, the ch.lip.com component is a compound 
name in the DNS naming system, whose syntax is right-to- 
iett '7 separated. The second comptjnent, sec^ is in the fJCE 
CDS naming system, whose synt ax is left-to-right 7' sepa- 
rated, litce XFN's syntax. The final two components, prEncipal/ 
jsmilh, are in the DCE security naming system. Tills naming 
system s syntax is also ieft-to-right '/' separated. Since a 
component is defined as the name between two XFN separa- 
tors, principal/jsmitti is two components even though lioth are 
in die same naming system. 

Composite names are formed when naming systems are 
joined by binding location information about a context iti 
one naming system into its parent context in another nam- 
ing system. Tins lt>cation information about a context in 
another nammg system is called a nfrtnffmififj-sysieni 
poiiUer. For most n^mmig systems a next -namiiig-sy stem 
poimer is boimd to a leaf name in its namespace and is 
treated like any other name in its namespace. The location 
infonnation is represented in an XFN reference. The XFN 
buTd operation cm\ be used to create next-naming-system 
pointers. 

Fig, 2 shows hoW' the name /..iWizcom/user/jsmfth/fs/naming/ 
memo.txt is composed. /... is a reserv'ed token that indicates 
the root of a global naming system. The Wiz.com component 
is a name m the DNS nammg system, user/|smith/fs is in the 
D(.'E CDS naming system, and naming/memo.txt names a DF^ 
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Fig. 2. Noxt-nainiiig-sy stem pointers (Wamxd h). 

file. Location infonnation about the 1)( JB ('l)S context in 
wliich user is boimd is associated witli Mte imme W\z m DNS. 
The aiomic name fs is bound in the CDS context user/jsmjth to 
an ol>ject reference with loeation information of jsmith's 
home direelory in DFS, W\i anci fs are naxt-naming-system 
pointers. 

Tilt* XP^N framework c<jn1rols path resolmion of a composite 
name. To re,solve i^J Wiz.com/user/jsrnith/fs/namfng/rnerno.txt die 
XFN framework fmst invokes the DNS context implementa- 
tion to resolve Wiz.com. The DNS context implementation 
makes libresolve calls to gather the infoiTuation it needs to 
form the XFN reference associated with Wtzcom. which it 
returns to the framework. Tlie framework inspeels the refei- 
ence and invokes the conteKt implementation specified in 
the reference. The framework passes to tlie context imple- 
metUation the location of the starting context for resohUi<m 
and the reniaining components to be resolved. In this exam- 
ple, the context inij^lementation is for DCE CDS, tiie starting 
context is the one named by Wiz.com, and the name to be 
resolved is jser/jsmith/fs/naming/memo.txt, CDS can only resolve 
user/jsmith/fs. It returns the XFN reference bound to user/ 
jsmirtr/fs and the remaining components to be resolved back 
to the framework. The framework then passes the remaining 
name, naming/mema.txi, to the file system to complete the 
resolution. 

XFN Protocols and Coitfigurations 

XFN specifies ciient-seiver RPC^ interfaces for use mth tw'o 
RFC protocols; DCE RFC and ONC RFC. The protocols sup^ 
port the operations in the XFN APL New namuig systen^s 
and some current ones are expected to use one of these 
protocols for their chent/serv^er conmiimications* 
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"The advantage for naming sysTems that export an XFN pro- 
tocol is that any existing XFX client that imports the proto- 
col can be used to conmnmicate with it. This is particularly 
useful for applications that neeti to export naming mier- 
faces. Apphcation programmers do not ha\'e to duplicate the 
client-side implementation and iJaey do not have to invent 
new naming interfaces. This pro\ides additional benefits 
such as the ability to use caching and other mechanisms 
provided by the XFN chent implementations, and a direct 
(and possibly more efBcient ) mapping of XFN operations to 
the naming operations,* 

The XFN naming model presents a hierarchical namespace 
that incorporates different naming systems. The iiaming 
systems are connected together into three levels. The top 
level is a global namespace: X,500 and DNS are expected to 
control this level. The next level is an enterprise namespace; 
DCE CDS, ONC NIS+, Banyaji StreettaJk, and Novell NDS" 
are considered enteqinse naming systems. The third level is 
the appUcatioii namespace. The DCE seciuity semce, a file 
system, and a desktop support apphcation namespaces. 

The XFN model, API, and protocols provide a toolkit for 
configiinng naming federations in various ways. Fig. 1 illus- 
trates a heavyweight XFN" client system with context imple- 
mentations and client-side code for five naming systems and 
a module that imports an XFN protocol, Fig. 3 shows a hght- 
weight XFN client svstem that only rims the naming module 
that imports an XFN protocol. Multiple name senders export 
the XFN protocol. Two of the name serv^ei^ use a variation 
of their context itiHJlementations to map arriving XFN calls 
to their natning systems' native opeiations. These sei-vers 
also export thpir native protocols to support clients miming 
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Fig. 3^- Ligliiweiglit XFN client configuration vMTh miiltiple name 
senders, 

legacy software. The desktop application was originally 
written to export its namespace with the XFN protocol. 

The two systems shown in F^g. 4 are a hght weight XFN cli- 
ent and a ser\ er fliat acts as an intermediary^ Like the client 
in Fig. 3, the XFN client in Fig. 4 only iims the naming mod- 
ule that imports an XFN protocol. None of the legacy sys- 
ten^' chent-side software needs to run on d^is system. De- 
pending on the client system's requirements, the XFN chent 
can be implemented and configiued to consimie more or 
less resources. For exan^ple, the XFN chent might defer to 
the caching mechanisms provided by the native immit^g 
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systeni clients. "The legacy najning systeni clients in Fig, 4 
reside on h remote system (similar to Fig. 1) that also ex- 
ports the DCE XFN protocol This remote client can be 
viewed as a surrogate or proxy client that acts on behalf of 
the initial requestor and performs the native naming system 
fuiu'tions," 

Another conimon XFN configuration combines Figs. 3 and 4. 
Some nanic^ servers export tlie XFN protocol and can be 
accessed ciirecdy from the lightweight XFN client. Otlier 
name systems are accessed \ia an XFN suiTogate client 

XFN Enterprise Policies 

TTie three-leve! hierarchy of global, enterjiniise, and appUca- 
tion namespaces is an XFN policy U'lat was mentioned in an 
earlier section. M;^ior entities, siicli as coimtries and organi- 
zations, are named in the gkil^al namespace. Names in a 
glolial naming system change mfrequently aiul require sanc- 
tion from a glolial authority to do so. The enterprise name^ 
space is tissiimed to contain names that are local to mi orga- 
nization. XFN policies provide some guidelines for 
structuring an enteiprise namespace. These policies do not 
at^ply to tlie globtil t>r appUcation namespaces* 

XFN poUcy recognizes that there me commonly named 
objects in an enterprise. Tliese are orgmiizadonal units, 
users, hosts, services, and files. XFN pohcy reserv es tokens 
to identify nanu'spaces for these objects and alstj applies a 
relationship between them. Table 1 siinuuarizes XFN enter- 
prise policies, Some exaniples of nanios that use XFN poli- 
cies are: 

• /.../Wi2.com/_orgynrl/r-d/eng/Ds./_user/ismith/_fs/naiTiing/rTiemD.txt. 
Names jsmith's file naming/memo.txt j smith is a user in the 
r-d/eng/os depaitment of the Wiz.com company. 

• /..7Wiz.com/_orgunii/s3fes/_user/nnjones/_service/caiendar. Names 
the calendar ser\ice for mjones who is a user in the sales 
depariment of ihe Wi; com conipimy. 

• A.iWiz.com/_prgunfct/newton/hldg300/conf'rrn/chaos/_service/caJendar 
Names the calendar semce for the Chaos conference roon\ 
in building 300 of the Ne\vi:on site of the Wiz.com company 

Piogrmiis that use XFN policies are niore portable ac-ross 
computing en\1romnents and emerju'ises. A dist ributed ap- 
plication, such as a calendai' senice, h^is a stm\daicl place (a 
^service context J to put its binding infonnation. An adminis- 
trator can put information about each user and each host in 
a central, predictable place. An end user can more easily 
figme out how to naitie anotiier users Hies, fur example. 

Despite the fact that XFN policies are minimal, they aie 
controx'ei'sial. Standard token names raise concerns of name 
collisions, XFN specifies these tokens on the premise that 
the benefits of a more structured namespace outweigii the 
risk that XFN tokens wHl collide with names that are al- 
ready in a namespace. j\n XFN uiiplemenration can sacrifice 
its portability and customize its ovtni tokens to identify the 
namespaces for common objects. Ai\ XFN unplementation 
can confomi to the XFN API but to some or none of the XFN 
policies. An enterprise namespace v\ ill nomiaUy ha\e many 
contexts that are outside of the XFN policy domain and may 
have additional pohcies of its own. 
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Other Naming APIs 

Some naming APIs, such as tJie DCE RFC Name Service 
hidependent { NSl) Interface^ and the OMG Conmion Object 
Senices Naming Service hiterface; ' aie customized inter- 
faces that may be layered over an XFN API and its 
implementation, 

The RPt' NSl provides a liigh level of abstraction for navi- 
gating a namespat*e and yieldmg DCE RFC location infonna- 
tion in the fom\ of f^PC bindinf^ lumdles. Tl\e OMG naming 
uiterf"ace is a suljset of the XFN basic context interface. The 
OMO imerliic e maps names to C'ORBA object references. 
Unlike UPC NSl and the OUG naniing interface, XFN ac- 
cepts many different types of ohject references mid provides 
mechanisms to extend the set of object references. Also, 
neither the DCE RFC NSI nor the OMG naming mterface has 
support for attributes. 

\Mien these customized interfaces are implemented over 
XFN, they take advantage of XFN benefits such as portabil- 
ity and federation mid they leverage all the soflwme that 
supports the XFN API. 

Conclumans 

Among the l>enefits thai XFN provides are: 
A unifomt naming interface for accessing different namlitg 
systems. 

Application progi-ammhig interfaces as well as RPC uiter- 
faces, 

A nmning syTitax for composite nmnes. 
Oi:^erations to jom different naming systems together into a 
naming federation. 

A frmnework thai supports the addition of new naming sys- 
tems to an XFN federation with no clumges to apjjlications 
or to current member naming systems. A naming system 
that joins a federation micst only supply a context imple- 
mentation tliat maps the XFN API or an XFN protocol to its 



32 



Ik'teiiibt-r ty9&Itewlt-tt-PacJ<ar(l J(Hin»a] ,, , ^ , ,^ 

©Copr. 1949-1998 Hewlett-Packard Co. 



nathe operations. Otherwise, the naming s^ysiems software 
is not changecL 

• Support for small eiients, 

• Easier adniinist ration of the various naming systems in a 
disiribuled computing environment. Browsers and editors 
that are written lo the XFN API can access an entire feder- 
ated namespace. 

• Application power XFN applications can access a wide va- 
der\' of naming systems through the same simple, ye( func- 
tional API 

Future Directions 

Future work neefls to be done on policy. Different \ eiKtors 
that offer similar ai>plicatioits need guidelines for sorting out 
their uses of die iiamesi>ace, I'sers somemnes wiuu to se- 
lect among similar or re|>Ucated services based on network 
topologj' or load balance. Administrators often liave com- 
mon infonnation about a group of users and customized 
per-user infonuadon. Namespace policies and sofrware 
could support these requirements. 
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HP Integrated Login 

HP Integrated Login coordinates the use of security systems and improves 
the usability of computer systems running the HP-UX'' operating system, 

by Jane B. Marcus, Navaneet Kumar, and Lawrence J. Ro§e 



The HP Intpgrated Login product pro%ades msyor usability' 
gains tor c^ustomei's deploying enlianced secnrity technolo- 
gies on computer systems based on the liP-L'X operating 
system, bi this ailicle, we describe tlie customer needs and 
the IIP Integrated Login sokition. 

As computer networks expand, and as pirates more ire- 
quenily travel the inrormatlon superhighway, customers 
require more stringent methods for securing dat^ and ac- 
counts. The base HP-UX operating system provides standard 
LTS'IK ■■' security mechanisms, but these do not meet all the 
needs of security-minded customers. There aie many secu- 
rity technologies available eommercially and in tin? public 
domain- IIP customers sometimes wish to deploy one or 
more of these technologies on the HP-UX platfomu 

Security tecluiologies use passwords to verify the user's 
identity and determme access rights to data and services. A 
user must enter a password and the paissword must be veri- 
fiefl before access is granted. For exaniplej basic HP-UX 
security requires thai a passworti be entered for the user to 
gain access to the HP-UX machine. In addition to machine 
entitlement* passwords also may be used to veril>^ the user's 
right to access protected ser\ices (e.g., mail systenis) in the 
user's environment. 

Security-minded customers see many henefits to deploy- 
ment of enhanced security technologies — for example, pro- 
tection against impostors and network eavesdroppers. liow^- 
ever, placmg additional sccmity teclmologies on top of tile 
IIP-LLX system can create a burden to the usei'S ofihe sys- 
tem. ^^Tien multiple seciuity teclmologies are deployed ( to 
monitor access to various protected services in the user 
environment), each technology' requires passw^ord verifica- 
tion. Thus, a user may be forced to tyi>e in a password for 
the HP-UX system and then for each additional security' 
technology. Furthennore, the use of multiple seciuit^' tech- 
nologies creates a complex task for users when passwords 
need to be chmiged in midtiple places. 

Customers need enhanced security, but they also want us- 
able systems. Customers want to operate in a familiar envl- 
rotuuent, and do not want to le^um many rievv comruatuls foj' 
accomplishing basic tasks. Wlten faced v\ if h a lengthy or 
complicated process, typical users may ultimately compro- 
mise the seem ity of their systems by wilting dovv^ pass- 
words and procedures that might otlienvise be forgotten. 
Customers will not accept a burdensome process for their 
users. 



HP Integrated Login 

Tlie HP Integrated Login product has evoh^ed to meet the 
customer needs discussed above. The original product for 
the HP-UX 9,x operating system was developed in response 
to DCEt customer requirements and was delivered primarily 
for use by HPs DCE customers, Howevei. with the HP-UX 
10.0 release, the HP Integrated L<jgin product has been made 
extensible, so that it can servT the HP-llX community at 
large. The latest HP Integrated Login provides hbrar^^ inter- 
faces that allow a generic set of securit>^ technologies to be 
integrated with HP-UX. The customer has maximiun flexibil- 
ity to choose and deploy appropriate teclmologies. Sitice 
DCE has an outstauding securit>^ technology, we expect that 
HP Integrated Login users will most often choose DCE for 
dteii- security needs, but the IIP Integrated Login product 
am support other technologies equally well. 

Tiie prin^ai^^ piiqiose of the HP Integrated Login product is 
to allow HP-lIX users a convenient method for incorporating 
otJier security technologies into the standaic! HP-UX envi- 
ronment. Lasers should be able to use fanuliar HP-l'X tools 
to accomphsh familiar tasks. Tlius, HP Integrated Login ex- 
tensions have been added to several staiidai^d HP-UX 10.0 
utilities. 

The most import ant functionality delivered Ijy HI* Integrated 
Login is a single-step login: the user enters a password once 
at login time, arul this password is used to grajit access to 
the HF-L X machine as well as verify access mnong all the 
contlgured security technologies. Tlie HP-UX 10.0 com- 
mands login and su have been enhanced to include single-step 
login capabilities. Also, the HP user desktop (HP VIE ) htis 
been integrated to support multiple seciuity technologies. 
Login information is propagated tliroughout (he entire \T'E 
session and logins need not be repeated when new \T.TE 
windows aie opened. 

Password consistency is fmidmnental to most IIP Integrated 
Logm deployments. A user chooses one password, ami Ihis 
password is adoptetl acrross all security teclm<:jlogies. Thus, 
tite user can supply the password once and the HP Inte- 
giated Login utilities transparently perform logins to each 
contignred security technology on behalf of the usen The 
HP-LT^ 10.0 passwd conmiand has l^een integrated to syn- 
cluonize p^isswords for the user, so that a requested pass- 
word change can be propagated to all configm'ed securitv' 
tet^hnologies. likewise, user information commands chfn and 

t DCE is the Distnt^uT&d Compirting ErtvirDnment. S&esmclB page 6. 
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chsh are pro\ided to allow changes to finger and user shell 
information across seciirit>' technologies. (Finger infonna- 
tion includes the users real name, location, and telephone 
numben) 

It is typical of the UNIX operating s\^tem that several opera- 
tions are pas*?word-controIIed — ^for example, file transfer to 
or from a remote machine and screen lock or unlock. Inte- 
grated file transfer protocol ( ftpj and IIP VUE lock utilities 
have been provided. Consistent with other HP Iniegrated 
Login utilities, these operations venfy user access for all 
configured security technologies based on one user-supplied 
password. 

The HP Integrated Logiu product provides extensions to 
HP-UX (M>ntniai^ds to support multiple securitj'' technologies 
on top of tlie HP-UX system. The extension method in%^olves 
anew^ shared library provided with HP-UX 1 0.0. Integrated 
HP-UX utilities make calls to tliLs shared librar>' (libauth.sl). 
The libauth bbrarj" calls handle various serurit>' tasks such as 
password verification for login and password changes. Thus, 
HP-UX utilities relinquish to fibauth the direct responsibiht>' 
for supporting diverse security technologies. Furthermore, 
these HP-irS utilities have no awareness of multiple security 
teclmology configuiations, and have no knowledge of tiie 
details of how these security technologies function. 

HP Internal Customer Needs 

Enhanced security technologies on top of HP-UX hav^e ex- 
isted for some time. Before the creation of HP Integrated 
Login, several security technologies hati independently been 
integrated into the IIP-I7X system. Each security technology' 
had it.s own login method, and each security product would 
spin off new versions of HP-l-X login commands and HP 
\TJE to incon>f>rate the te(*hnolog>s login implementation. 
These efforts were diflicull to (^oorflinate, and there grew lo 
be many different versions of HP4TX login conuoauds lo 
accommodate till of these security tecluiologies. One HI* 
hitegraled Login goal was to replace the myriad of login 
im pi e men tat i Otis with one generic login methodology. This 
was expected to solve a number of different problems, in- 
cluding the HP suppori cost to maintain multiple code 
bases. The solution required t\w tlelljiiljon of a generic logui 
procedure, llexible enough to accommodate all the existing 
login methods. 

Extensibility 

HP Integrated Login supports multiple security technolo- 
gies. The MP Integraterl Login {configuration file declares 
which technologies are being integrated. TVpif'^ly. tbe 
llP-l^X machine administrator uses HP Integrated Login 
admirustrative tools to create arul maintain Oiis coiiTigtu-a- 
tion file. Each teclmolog>^ declared in HP lutegmtetl Login's 
configuration file must provide a technology- shared library. 
This shared libnuy^ will he dyr^ainlcaKy loaded hy the HP 
Integrated Login library (lihauth), which coorilinates all un- 
derlying security rechnokjgies. The libauth librajy detennines 
the names of the teclmology shared hliraries and the order 
in which to load tiieni based on the contents of the HP Lite- 
^i ated Login configuration file. Hg. I shows the resulting 
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Fig- 1 The ext<»nsible architccmre of HP Integrated Login. 

ai'chitecture. The libauth library needs no special knowledge 
of any security technology' hbrary that it loads, WeU-defii^ed 
interfaces exist between the libauth coordination Ubrary and 
the security technology' shared libraiy. 

From HP-tiX commands, the follov^ing can occtm 

• The HP-IIX conmiand dynamically loads the HP Integrated 
Logm shared libraiy ( libauth ). 

• The libauth Ubrary reads the HP bitegrated Logiu configura- 
tion file and dynamically loads the configured security tech- 
nology libraries. 

• The HIM'X command makes libraiy calls to libauth to handle 
login and password ftuictions. 

• The liba Jth library makes Ubrary calls to security technology 
libraries. 

.^\n exception in the IIP Integrated Login Ubraiy strate^ is 
the method by which btisic HP-UX security is provided. 
While the HP Integrated Login configuration may specify the 
use of basic HP-UX security tJiere is no HP-UX technology 
Ubrary to be dynamically loafled. Rather, the HP-UX com- 
mands handle basic HP-UX functions fi^om within the com- 
mand code. 

The fibauth library is shipped with the HP hitegrated Login 
product, and is dynamic^dly loaded by the integrated HP-UX 
commands and HP YUE. HP-UX utiUties use libauth to inte- 
grate seciulty technologies, but the basic HP-llX secnrity 
code is always accessible since it m contained v^ithin the 
HP-UX utilities. Thus the HP-UX 10 J) utilities can still pro- 
vide standard HP-UX runctiouality on systems that do not 
have libauth uistalleth Wiiie the integratetl cotnit^ands must 
be aware of their use of libauth^ the commands are conv 
pletely mi a ware of Itbauth's use of underlying security tech- 
riokigy lihnuies. 

Configuration of Multiple Technoiogies 

The HP Integiated Login contigiuation file is used to define 
a login poUcy lo be used on a [^articular machine. Tlie policy 
specifies which technologies are in use. When nurltiple suca- 
rity tec;hnologies are in use, the relative priority of these 
technf)k>gies timsl lie ctju figured for HP Integrated Login 
opera! ioru One iechnuJog>' is configurefl as the primary login 
teclmology. This prunaiy login technology will be the inidaj 
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lechiiology to be coiisiilte<l for aser password verification. If 
the primaiy login sue coeds, the user will be gr^iuiled acTew^ 
to the ITP-IJX ruachiiie, and additional logins fan then pro- 
ceed (transparently) to verify the user with other security 
technologies. 

In rase tJie priniiir;^' if>gin floes not succeed, a fallback teclv 
nology can be f^onfigured. If the user can be verified with 
tlie fallback: security technology, the user is gnuitefi access 
to the HP-UX machine, and again, other contlgured logins 
can then proceed. 

The imiMiiianre of The fallbark strategy' cannot be under- 
stated. Security tecluioiogies often have dependencies on 
network commiuiications and cannot function if the net- 
work is not intact. For some customers, it is imacceptable 
for users to be tienied access to tlieir local machines be- 
cau.se of netwcjrk problems. The IIP Integrated Login fall- 
back k strategj^' allows ruskmieT^s who require a liigh level of 
robustness to use HI* producis with confidence. 

The relationship between tlie primary login teclmology mid 
the fallljack li>gin technology must be wcO-underatood. hi 
some CcLseSt the |)riinar>^ login technology may attempt to 
synchronize the falll)ack technology with current user infor- 
mation. For example, when DCE seives as the priniar>' login 
technolog5^ it is an IIP Integrated Login option to automati- 
cal ly ]3opulale the HP-UX user information database (i.e., 
the /etc/passwd file) wilh iivftinnation from the DCE security 
database. In mo.sl cases, the /etc/passwd file will never be 
accessed at login time, because DCE. as the primary login 
techiiology, will verify die user. How^ever, when DCE Ls un- 
available, HP-UX login secmity can be used as a fallback to 
log in all users known to DCE. Such an arrangement is ad- 
vantageous for adniinisl rators who want to maintain user 
accoimts in one primary location, but also want to facilitate 
fallback logins where necessary. 

hi other cases, administralors may puiposely wish to main- 
tain some iisei-s in one s(^curity tecluiology database and 
other users in a different seciuify technology database. The 
HP Integj*ated I^ogin configmalion of primary' and f^illback 
logui teclmologies can facilitate this process. The HP hU€^ 
grated Logm libauth librai'y will consult the primal^ login 
technology first to verify the user, but if this user is not 
known lo the techi\olog>'. HP Integratefl Login can be config- 
ured to consult the fallback login teclmology. 

In addition to conligured piimtuy imd fallback login technol- 
ogies, othei' login lechnologies cjin be conJlgurecl Thest^ 
logins will be done transpmently for tlie user, in the order in 
wliicli they have been conligured witli HP Integrated Login. 
TIie pur[jose of these additional logins may be to enable user 
access to some protected service in the user's en\Tronment. 
Tliese additional logins will only ^>e attempted if the prinuii>' 
or fallback login has succeedetJ, that is, if this user has been 
gnmtetl access to the HP-l-X machine. Eixors occuning with 
these additional logins are nonfatab meaiung that the user 
session can proceed even if one or more of these additional 
logins fails. 

The organization of technologies m the configuration file ts 
used by libauth lo deteniune the order hi which lechnologies 
should be loaded and accessed. We call iibauth's ordering of 



technoiogies tl\e poUey cliaint and It reflects the configura- 
tkm of j)rimai7 loghi. fallback, and adflirional login lechnol- 
ogies. The policy chain is used liy libauth to make deinsions 
on how to sequence through tlie configured technulogies. 

The contlginalion file may also contiiin cUreclives to itbauth 
regar<iing handling of logui errors. Tliese directives logicjilly 
l>ecome part of libauth "s policy chain and deiemiine libauth 's 
actions in the event of login failures. For instance, die con- 
figuration file may specify that a logui failure because of an 
inc!on'eci jiassword entry shouhl result in a denial of ma- 
chine access, regardless of wheUier this password may be 
verifiable by other configured technologies in tlie policy 
chain. The libauth lilirary s actions in this case would be to 
stop Uie login setjuence after [he initial failure and refrain 
from cycling through the security technologies. The behav- 
ior of libauth is conngurab!e. so it is also possihle to specify a 
configuration that authorities libayth to pass the logui request 
to the next teclmology hi tlie pohcy chaui. 

The configuration file also includes a mechanism to pass 
configuraTioji informal ion lo the secmity technology li- 
braiies that will he loaded by libauth. Configurable parame- 
ters can be specified for each specific security technology. 
These parametei^ are mcaningfid only to the security tech- 
nology lituary and jue deiermined by the security technol- 
ogy^ lihrajy ])rovider. For instance, a specific security tech- 
nology may support the notion of a session lifetime. A 
configurable parameter called LIFETIME may exist in the HP 
Integrated Login configuration file to be piissed to the secu^ 
rity teclmology when being loatled liy libauth. The libauth li- 
brar^^ will pass tlie configuration infoniiation to llie security 
teclmology library, but wiU not use or process this informa- 
tion in any way (thus preserving the extensibihty^ model). 

HbaulEi Login Processing 

To accomplish a login that results in a user session, several 
behind-the-scenes events must occun The procedure con- 
sists of three phases: die initiiiliiiatjon phase, Uie login 
phase, and the session-setuji phase. 

During tlie tnitialUation phase, the HP Integrated Login 
policy is read from the configuration file. The Itbauih library 
proceeds to load the security technologj^ libraries and 
charges thtmi to i^un through their resjiective initial ligations, 
Initializaiion failures from any oi the security tecbnologj^ 
librmes cause libauth to maik tlie techno log>^ as inaccessible. 
When security technologies are inaccessible, libauth must 
acljust its understanding of the policy ch^iin to reilect the 
effective i>olicy. I'pon successful initialization, libauth and the 
security technology hl)raries exchange entr>' point iiiffjnna- 
tion. This makes it po.ssible for two-way rcHummiication to 
occm' between the securitj^ techno I og,v library and libauth. 
The libauth hbrar>^ can now call die security teclmologv li- 
brary^ uiterfaces to handle seciirit>' tasks, and the secmity 
technology libraries can communicate messages and error 
status. 

The login phase is a two-step process. Step one determines 
whether the user should be grtmted access to the local sys- 
tem. Prompts are issued for the user name and password, 
and subsec^uently the prhnaiy- login technology librar%' is 
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caUed to verify access. Logically, this stef> niay be consid- 
ered a Boolean opc^ration which siniply retunis a yes or no 
answer regarding the user s entitlemenl to access the Itx^ 
system. Depending upon tJie conRgured policy chain, tibauth 
may continue on failure to the configured fallback lechnol- 
og\\ or Qiay deny access. 

Tile second step in tliis iogin phase (after having granted 
machine access) is to complele any additional logins that 
should be done. These additional logins niay be needed lo 
enable operations with some protected services once the 
user session begins. In current iniplementations, additional 
logins can only succeed if the pas?5worri entered is valid for 
this user across all security' tecJuTiologies. However, libauth 
code is in place to support different passwords for adtii- 
tional security lechnologies. although this code is not yei in 
practical use. Tlie method for supimrting multiple i>ass- 
words depends un the ]jrunary* login technology^'s abihty to 
securely store passwords to be ttsed with other security 
teclmologies- A successful logm with the prifuar>' login tech- 
nology would result in the stored passwords being passed to 
libauth for use with the other tecluiologies in the policy chain. 

Tlie session-setup phsise is for establishing the user session. 
The inthrniatioii alioLit how to set up the session is retrievcfi 
from die miflerlyuig primai^^ login tec:lmolog,y database, hi 
particular, die user and group IDs must be set for the new 
session* and the user shell tnust be started. In addition, the 
exf)oitation of environment variables occturs. If aiiy config- 
ured teclutologies retiuire special en\iroiunent variables to 
be set, these emironment strings are piissed back ro the 
HP-UX conmiand so that they are exported al session-settip 
time. 

Password and Itiforination Processing 

Tlie libauth library hiterfaces oversee changes to user inf<3r- 
mation, such as password, user shell, and finger infoni^a- 
tion. The HP-IX passvvd command, im exarnf^le, Itjads fibaulh 
to coorfhnate password changes. The (ibauth (ajul leclmology 
libmr> ) initializadon pliase tiescribed for login processing Is 
the first step here as well 

Before calling Hbauth U) make a password change, the passwd 
t^otmnitnfi calls libauth to chet^k the new password that has 
heen proposed. Most secinily leclinulogies artply passworrl 
Htretiglh chec king iilgtHithrns tn newiy created user pass- 
wor<ls. These algoiiduns lest wliether the new passwfird 
meets certain criteria. For example, one HP-ITX reqniremen! 
is that the new password inu.st have at least two alphabet if 
eharaeters aivd at least one juimeric or specl^d rhararier'. 
hV>r tJtLssword strengtii checkirig, a jibayth intei-face deter- 
mines if the selected password is acceptable to ail config- 
iired security technologies. The password is rejected if any 
fjf Ihe .security tecimology libraries rejects it, and the operas 
fiiin fails. 

If the proposed password is acceptable, the command calls 
libauih to contact the primary login tecimology. Tiie priuuu-y 
login tecimology will dieu ch^mge the i^assword in tht* pri- 
tnaty kjgin technology's user datai)ase. Failure to change 
informatirm correctly wilb the primary login technology 
causes tlie entire operation to fail. Ifihe cfiatige sueceeds, 
libautti follows the ptjlicy chain to request password changes 
in jill other security technology databases. If a failure occurs 



far this user with any of the additional (Le., optional) tech- 
nologies, an error indication is recorded and the next reciv 
nologj' in the chain is tried. If a failm^e occurs dining a pass- 
word chiitige operation* the password may mt longer be 
consistent acrcjss all technologies. An error indication 
clearly states this and giv^es ad\ice on how to remedy the 
situation manually. 

Some <letails of the poUc\ chain configmed in the HP Inte- 
grated Login configuration file do not apply to passworti 
processing, Tlie configuration file is used to determine the 
primary' login techncilogy. However, libauth password inter- 
faces make no attempt to deaJ Vkith a configured fallback 
technolo^ in case of erron 

The Itliauth iilinir^' interfaces allow other user information to 
be changed. Tlie user's shell can bt* also changed In all 
cases, changes to user niformation start by attempting to 
make the change in the database of the priniaiy^ login tech- 
nolog.v, Successftil chajiges cause the opei-ation to continue 
down the policy chain to completion. 

Other libauth Interfaces 

Aside from passworti and login functionality, other fibauth 

interfaces are available to HP-UX commands. 

F\^r secttrity technologies that include the concept of login 
expirations, libauth sup[;)orts a refresh operation. For exam- 
ple, suppose tiiat the user's machine hits been left locked by 
the WE screen lock progi-am, and the user s login exjjires 
before the tiser retiuTis to unlock the juachiite. The fibauth 
refresh interface allows bypassiitg some of the details of I lie 
tiill logui process, althougli reprompting of the passwT^rd is 
rcHiuired for tliis step to ttrainiatn st*curit;y- 

AiiotJier libautti interface resets the current login information. 
This interface is used by conmtands that can switch be- 
tween users, such as ftp ancj su. The resel miction clemis up 
any residual hjgin inibrinatton. elTeelively terminating a pre- 
\icMis login across all security technologies, 

(vhooKiing a Primary Security Tecluiology 

An IIP Integrated Login goal is to simiilify user administra- 
tion among multiple security lechjiolcigies. Wlien rmiltiple 
security technologies are deployed, mtdtiple user mfornta- 
tion databases may coexist. These rcgijs fries are reposito- 
ries of user- related information, and different tecluioh>gies 
require the siorage of dilfereiit (ypus of information about a 
user. HP Integrated U>gin ronfiguriition of a primaJ^ login 
technology detennines which registry is most imp(jrtant for 
maintaining user infonnation. Tlie primai-^' login let Jutolo- 
gy's registry assumes the role of the mmn location for user 
information, anrl registries from other technologies are log- 
ically subsei'\ieiU. Foi' example, if the password that the 
user has prrn-ided is detemiined to be incorrect when 
checked agaittst the main regis! ly, IIP hit (^grated Login niay 
he conJlgureil to deny access wit lion I fmlher checking of 
the password against odier technologj^ registries. If the user 
reqitests a cliange of password tmd for some reason the 
ntain registry cant^ot entertain the change, no attempt is 
made to rcH|uest the chaitge in other registries. 
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When (leployiiig multiple security technologies^ the choice 
of ihe m^tin registry is ver>' sigiiifiraiiL SysK^ni admljiistm- 
tors might ask what features such a registiy sljouUi have. 
Especially in a networked environment., this rc^gistr^" must 
be highly available and reliable, since users may he denied 
access if it is not in ojicration. The n^ain registry nujst be 
capable of storing critical iLscr iiifommtion, mcluding but 
not limited to user name, user identifier, password, group 
icientilitT, home directoryj and login shell. Since user infor- 
mation m likely to chimge as we move towards more co nip lex 
systems, built-in extensibility of the regislrj^ is higlily 
desiral>ie. 

We find DVK to be an excelleni choice for the main secimt^-^ 
techntjldgy, n\e DC'E security service legistry satisfies all 
basic requuTments for a main registry. 

The DCE registi'y is highly available. Tlie implementation 
alJows for a ( oOcction of one master anti sevei-al re[)licas, so 
liser infonnation can be obt^uned from multiple (Tjut consis- 
tent) sources. Replicas are copies of the master information 
and are readonly sources of inforttiatiorL If a rephca goes 
out of service, others are available lo provide user informa- 
tion. If tJie master goes down, a suitable rei)lk:a can be 
transformed into ;i master. If semce degrades because of 
heavy demand. additiontU replicas <im be added to expedite 
requests. CVjnsequetitiy, the senice is scalable and rehable, 

DCE uses Kerberos^^ authentication protocols and is highly 
secure in a distributed en\'ironment. For example, DCE does 
not transmit passwords in (he clear across the network. This 
feature is not pcU't icularly useful if other tedtnologies do 
otherwise, but the main registry should not l)e the weak link. 

The OSF DCE IT regisliy is extensible. System adniinislra- 
tors can exleiul the registr>^ to hold arbhi'ary- user infonua- 
tion. For example, DCE 1.1 uses tliis extensil>ility feature to 
support password aging (mandating that passwords f^e 
changed regidarly) tmd password strength checking?, 

DCE is serviceable, Ix>gging and audit ti-ails can be used to 
diagnose error conditioits. 

In sumniary, we find DCE to be the logical choice for the 
printary login technology and lo sene as the main registrj^ 
of user inhjnnatitjn. (See the article on page 41 for more 
information about DCE security senices.) 

Login Access Using HP Integrated Login and DCE 

Although the HP Integrated Login design does not letjEiire il, 
our implementation works veiy well witli DCE providuig the 
main registry' of user uifonnation. This solution is robust 
and aUows athninistratoi's to focus tlieir effoits on maintain- 
ing user iiifomiation in otie location: ilw DCE re^gistr>-. Fig. 2 
iDustrates how HP hitegrated l^gin uses tJte DCE regisoy. 

Customers with robustness requh-ements often choose to 
configure HP-UX security- as a fallback iecluM>logy. As <le- 
scribed earlier, the fallback tecluiology is used \vhert the 
primary login technology' is unavailable. With DCE ;is the 
pilmaiy login tecimolog>; t)CE is unavadable when the net- 
work is not operarional. Since HF-l'X seciuity^ is local to the 
machine and is unaffected by network errors, an HP-UX 



fallback may be a good choice. However, if the fallback reg- 
istry is to provitle access that is consistent with the maui 
registry, il rntist lie kept consistent witli the main legLsti^'. 
Stipj>ort for keeping rlie registries syneltronized is obviously 
needed. 

For this puri>oseH DCE provides a tuoh passwd export, that 
exports the infonnation in the DCE registrj^ to the native 
HP-UX registries, /etc/passwd and /etc/groups. Wlien IIP Inte- 
grated Login Ls installed, a system administrator c^m config- 
ure die HPTJX command cror to nin passwd export periodic 
caily to keep the registries consistent. 

D('E user accounts are valici acniss the DCE network envl- 
ronnienh Once established in the DCE registry, a DCE user 
t an lo^ in from any machine in the iiser^s fJCR envhotunent. 
witii ncj other special administration required. Th<^ DCE reg- 
istry is implemented as a centralized network ser\dce, with 
requests travelling l>ack and fortJi <iver the network from the 
registry' to the clietit machuies. However, DCE tUlovvs regis- 
try user uifonnation to be overridden at the local maclune 
level In this case, infontialion is taken from the local ma- 
chine rather than from the DCE network registiy. An over- 
ride nieciianism is important to machine administrators 
wisbuig to cusTomize their indivitlual machines. Ftjr exam- 
ple, in a traditioniil I NIX system, earh nuichine has n sujjei- 
iiser accomit root. Machine adtninistraloi'S do tiot WtUil liie 
root account to share a i>assword witli all root accounts on 
machines in the DCE networked environment. Rather, ma- 
chine administrators want to maintain the password for the 
root acc^ount locally, hi tliis case, adniinistratoi's must fjver- 
ride the uifomiation in the main registry- in favor of inh)rnia- 
tion stored on the local machine. 

To hajidle such cases, DCE provides support for an oveiTide 
file This file has a format similar to lite traditional UNIX 
/etc/pa sswd file. If a user is maintained In the override file, tlie 
nser s access to die n\achine is \ erifiecl based on the over- 
ride file entry and is not vc^rified by the DCE registrj. By 
common use, root is maintauied in tlie override file I o etisure 
that for supeiiiser pr ivih^^ges a local i>assword is lequired. 
The DCE override file is only readable by tlie supeniser ac- 
comit and as such is more seciue than the liP-UX /etc/passwti 
file. 

Since DCE is a scalable, reliable, and seciue senice, some 
mstallations witli especially stringent security requirements 
may wish to disable fallback login \ erificatiDn. \n general, 
cuslonu^i-s can rely on DCE to provide consistent ser\ice a^ 
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long as the network is operational. Some customers disable 
fallback to basic HP-UX securitj' because the HP-fX fmcJ 
passwd file is inherentiy less secure than many customers 
require. For HP Integrated Login DCE configurations with 
tKJ fallback iet^bnolo^\ most logins will be disable<i if tiiere 
are netT^ork problems. However users bemg administered 
ill the DCE override file will still have login access in case of 
network faihire, since the override file b stored on the local 
machiiie and is unaffected by network errors. 

Login Information Maintenance: DCE and HP*IIX 

Suppose HP Integrated Login has been configured with DCE 
as the primary* login technology and HP-CX securitj^ pro- 
vides the fallback technolog>'. 

Example 1, A tiser wishes to change a password. We have 
i\^ registries to consider: DCE and HP-UX. The following 
set^uence of e%-ents occurs: 

• Since DCE is the main registry; the old and the desired new 
passwords are obtained and ]>assed to I he DCE security 
technolo^^ librarv^, 

• The DCE registiy \ eiifies that tJie old password was coiTect 
and further detemiineJs if the new password is strong 
enough. If these checks pass, the user's password is 
changed in the DCE registry'. 

• Uo attempt is made to contact the fallback regtstTy (/etc/ 
passwd ) at this time. However, iibauth could propagate the 
password change to other configured tccluioiogies. 

• After a cert^i interval configured by the system administra- 
tor. passwd_EKporE rims and exports the changed pttssword 
infoniiatiou to tlu^ HP-lIX /etc/ passwd file. Thiis, iJie fallback 
plan to HP-UX remains intact with this synchronization. 

Example 2. A user whose account information is stored in the 
DC PI ovemde file requests a password change: 

• The iibauth library passes the request to the DCE security 
technology lUirtir^. Wlieii user accotmt infonuafion is kept 
in the DCE overritle file, i)asswon!s are <4um|^ed in the over- 
ride file only. The DCE registry is m<i! changeci at alt 

• Wien passwd_export riu^s, it exports tiie changed pass wort! 
from the override file to /eic/passwd. Tliia is how the local root 
user can change its password. 

Example 3, A user ret^uests a shell change: 

• The chsh comjntmd calls NhauTh to pass the new shell infor- 
mation to the priniajy login technolog>' libraiy (DCP]}. 

• If configureiK pas&wd_export nms and ex|)orts the changed 
shell infonmation to the HP I :X /etc/passwd file. Thus, HP-UX 
and DCE registries remain synchronized. 

If pa sswd. export is not run periodically, some traditional l^NIX 
commands and libr'rir>' calls with dependencies on the /etc/ 
passwd file j night use stale data. For example, the Is com- 
mand gets tiser information fron^ the /etc/passwd file. If the 
/etc/passwd entr>^ for this user is not kept consistent witJi the 
information in the DCE registry^ the Is command may be 
relying on old rlata for this user. 

Logiti Iiifurmatioii Maintemuice; NIS and DCE 

Sut)]>()^?e HF' [ntegrated Login has been ( onfigured with 
fH^-l'X 'AH the pnmar\ ]t>,s*in Irchnulogy, By way of clarifica- 
tion, it ,'sltoiilti bv ntjted tliat MS sirpport falls iliider tlie 



generic HP-LIX umbrella because HP-UX commands have 
b€?en integrated with NIS for several years. At present, the 
code to support SIS is retained in the HP-UX conmiands. 
Thus, wheti HP-l^X security has been configured, ihis effec- 
tively can m elude MS if h has been deployed irt the HP-UX 
environment. Currently tiiere is no way to ensure full ac- 
count consistency^ between NIS and DCE liecause there is 
no NIS utility^ comparable to DCE s passwd_eKpDrt. Thus, users 
added to the NIS registry^ must also be added to the DCE 
regLstr\' by the system administrator 

Example 4. A user pass^vord change is requested and the 
HP-UX system (MS) Ls the niait> regisirj'. that is. passiFord 
verification by NIS detennines the aser s right to machine 
access. Suppose also that DCE has been configured for adtii- 
tional iogm because users need access to some DCE 
services. 

• The user vilshing the passwoi^ change must present the old 
j)assword ajid the desired new password. The passwd com- 
mand caUs Ifbautti. 

• The Isbauih library'' tells the passwri conunand that the HP-UX 
system has been configiu'cd. so the pssswd conmiand iuMne 
code handles this password change operation. 

• If the user's account is in the local /etc/passwd file, the pass- 
word is changed there. If the user's accotit^t is iiiaintained in 
the central NIS registry, the pass wo id is niotlified there. 

• TIic passwd conmiand caUs Itbauth to propagate the password 
chiinge to other configtircd registries. This request is passed 
to the DCE lechnoJogy^ library and, if successful, results in a 
password change in the DCF^ registry. If for some reason the 
password cmmot be changed m the DCE registry, the user is 
advised to try chiuiging the D("E password again later. The 
passwd command now provides a command hne option to 
change a pass won! in a specified regisiry. 

The Single Sign -on Problem 

HP Integral ed Login operates on HP-tlX machines only. 
Much work remains to be tk>ne for customers who need a 
hlglter level of nexihiihy mid integration. For examtile, a PC 
user on a Novell netwtjrk vvonUl like f(j enter a iiassword at 
network login time i\m] have this jiasswfjrd nlsa validate 
access for other integrated systems. Unfortunately, there are 
extremely complex problems associated with login and 
password synchronization across operating systems £ind 
across hardwiue platforms. This larger prol>lem is c^ften 
called the single sign-on problem, and is beitig addressed by 
an industry working grotip of which HP is a coleader. ^ 

Summary 

The MP Integrate*! Logui product addresses the needs of 
ciistomers wishing to deploy multiple security technologies. 
HP Integrated Logir^ improves usability by provitlLng single- 
step logii^. Options to configure fallback k:>gin technologies 
ensurt^ robustness m die event of network fiiilure, HP hne- 
grated Login is especially convenient for customers deploy- 
ing DCE. because DCE antl IIP Integrated Lf)gin together 
provide the tools required for maint^iining a high level of 
consistency between DCE ;md the HP-UX system for user 
account information. 
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The DCE Security Service 

A security protocol consisting of encryption keys, aythentication 
credentials, tickets, and user passwords is used to provide secure 
transmission of information between two transacting parties in a DCE 
client/server enterprise. 

by Frederic Gittler aiid Anne C. Hopkins 



T^ie Open Sofi^^are FoondatiDTi s DistJibutecf C(^mputmg 
Eii\1r(>mnenl (DCE) is a roIJection ofiniegrated senices 
iJial supj)oil thp distribution oi applications on multiple ma- 
rhines atross a network, Irt most cases, networks are inher- 
ently in.sc< lu^e because it is possible for someone to listen to 
traffic or behave as an inijiostor. Uldiout comitemieasures 
rhis Ou-eat C'ouici prohibit the distribution of business appli- 
cations. 

The DC'E security senlce described in this article pro\1<les a 
set of security mechanisms that can be easily used by a ciis- 
tribnted application to renu>ve the security vnilnerabilities 
mentioned atiove. 

The security functionality provided tiy lite DCEsecmrity 
seni<*e includes: 

• Idetitifi cation and iiutJientication of users to veriii' that ihey 
are who tl\ey claim to be 

• Authorization for applications to decide if a user can access 
an (Jt>eration or ohjf^ct 

• Secure data conuminical ions io (notect the data commimi- 
caf ion of an applkatjon agauLst tmnpering or t^avesdropping. 

Security Services 

The D('E seciuity service, witii additional n^w services and 
facilities, is based on th*^ K(^ r tie ros system J The Kerberos 
system periVjnns anthcnticiitioii of users and seners based 
on crj^jtoj^raphic keys so that connuunicaling parties can 
tmst the itlenlity of tlie other IJ(T^ augments Kerberos with 
a way to transfer acldiiional security attributes {beyond just 
idetuiiy) to a senvr wliich may choose to perfonn access 
coulitjl on dujseallributes. Hie IX'E connnunication proto- 
col contains support for protected conimunications that 
relies on cr>tf)grapiuc session keys provid€*d by Kerberos. 

Flg^ 1 shows the envinamient in which tlie DCE security 
servi<*e operal.eSf ar>d the sertdces provided on the DCE 
se<*urity sei-v^er. 

Registry. Ev'er> DCF!! set u lit y service user is known as a prin- 
eijuil. Iiiti'raclive^ (Imiiutn) users, systems (computers), and 
ai>pli*'alioji servers (processes) are all print ipals. Kacb prin- 
cij>;d shari^s a secret key t with the DCI^ secHtrity server. Tlie 
secret key for interaclive users is derived from the user pass- 
word. This security nu>del n^llt^s ou tlie fact that a particular 
key is known only Io tlu- (mruipal antl die DCE security 
service. 

? As in tha Kerbems system, fcays ara used tor encrvpting and decrvplmg data iranstored m a 

netwDrk iraiii;actiDri, sikI QfQ kmwn only to the DCE seconty serv&r and tire parfieii inynlved in 
the transact I nn 



The registry senice is the manager of the central registry^ 
database whicti contiiins the principal's name, universal 
unique idenlifier (t'LTD), secret key, UNDt' account attri- 
butes, and otiier attributes of the principals* Tliese attri- 
butes inchide the extended regis1r>^ attributes (ERA), wMch 
may be defmed and instimtialetl i)y an administrator. 

Like other DCE services, access to the i egistry .service is 
based on the use of remote procethne calls (RPCs). The 
registry's operation is seciu^e because it uses a protected 
RPC for all of its transactions, Extejided registry attributes 
are c'overe*! in more detml later in tills article. 
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Glossary 



Tlie fallowing are some of the term ina logy and associated acronyms frequentfy 
ysecf m this art?clp. 

Extended Privilege Attribute Certificate (EPAC}. A credential provided by the 
DCE privilege SEfvice containing user and group [dentities and attribute- value 
pairs. This information js used by an application server to make authori nation 
decisions. 

Extended Registry Attribute {ERA). A n^echanism in which attrfbute-value pairs 
are a^sGCiaien vvith principals The inforrnation in these attribute-value pairs may 
be used in deny or grant an autrionzation request, 

Principal An entity such as a user, an application, d^ a system whose identity 
can Ge authenticated. 

Service Ticket A credential used by an application client lo authenticate itself 
to an applEcatiDn server 

Ticket-Granting Ticket (TGT). A credential thai indicates that a user has been 
authenticated and is therEfore etig^blB to get tickets to other services. 



Identificatioti and Authentication. The fii-j^t interaction between 
a user and the EiCE security servic-e is the login setiuence 
when the identity of a user is authenticater! by a .secret key. 
The result of this authentication is a ticket -granting ticket 
(TGT) containing the UJ^er pi incipal's credentials. The TGT 
indicates that the user lias l)een authenticated, h is used, as 
its tianve implies, to obtaui tickets to other services. The life 
span of a TGT is limited to ensure that the user t^epresentetl 
by the credentials is the user cnnently using the sy stent antl 
that tlie user's credentials ^ife up-tfj-date. 

Tlie uset^ and group itlentity and the extended registry attri- 
butes are not paii of the TGT issued by the authentication 
service. The privilege senlce supports m\ additional autho- 
rization by providing user and group itientities and attiibutes 
in the Form of an extended privilege attriljute certificate 
(EPAC). Durhig a login sequence, after the TGT is obtained, 
tine iim-time DCE secuiity senice makes a request to the 
privilege serv er to issue a privilege TGT This ticket is a 
combination of the TGT and a seal of the EPAC. 

The privilege TGT is stored in the user's enwonment and is 
used by the secure conmimiication mechanistns to obtain a 
service tit ket front the authentication semce. The service 
ticket is tised by tlie comnninication mechanisms to per- 
form mutual authentication beti^^een the apphcation chent 
and the apphcation serv^er. 

In each of tiiese exchanges, secret session keys. v\iiic"h are 
known only to die DCE security service serv^er, are generatet 1 
for a particular session between the ciietil and server. The 
DCE security nm-time enviionment, RP(\ and GSH (Generic 
Security Service)- API use these keys for data enciypt ion or 
integrit^'^ protection general ion in any netw ork communica- 
tion diuing a particular session. A l>rief description of the 
GSS API is given later in this article. 

Authorization. DCE secmiti,' provides application ser^-ei^ 
u iih multiple options for aut horiication. A server can choose 
to grant access to a user has^d on one of the foiloT^ing three 
ntodeb. 
• Nanie-based authorization. The simplest but least scalable 
way of dou^ authorization is to compai-e the name of the 



remote principal vvitJt die names stored in an application- 
specific datatjasf\ Tliis method is caUcd name-based autho- 
rization and is available when using the DC^E secure com- 
munication mechanisms. 

• Privilege-based authorization with access control lists. DCE 
serv en* can choose to protect their resources with access 
control hsts TACLs). Aji ACL contains entries that descrilx^ 
tlie piiilicular [jennissions granted to various principals. Aii 
ACIj entry may specify' an mdividual user (prit\cipal) name, 
a group name that implies several |>rincipals, or "otiier** to 
indicate any principal not aheady matching a user or group 
entr>^. Csers» gioups. and others from a foieigu cell may also 
be specified in an ACL entry, 

lATien a server receives a remote request, it asks the authen- 
ticated RPC rim-tmic cnviionmcnt for the caller s EPAC\ The 
EPAC contains the caller's i3iincipal and gioup identities, 
which ai'e compared against the ACL to determine if access 
is granted If tJie chiller s principal identity matches the [>rin- 
cipaL in an ACL entiy. ami if that ACL ent I'j contains I he re- 
quired pennissions. then access is granted. If there is no 
match on the principal, but one of the caller's groups matches 
a group ACL enti'y. then the pennissions in the gi out; entry 
apply 

The DCE library includes facihties to manage ACLs artd per- 
form authorization checks based on ACLs. ACLS are de- 
scribed in the article on page 49. 

• Otlier authorization. Other anthoiization mechanisms are 
made possible by the ERA facility A sciver can use the 
valne of any given attribute in a user's EPAC to decide 
whether it should service or deny any given request. 

Secure Data Communication 

[)CB provides the remote procedme caU (RPC) communica- 
tion mechanism as one of its core semccs, Tlic DCE secmity 
service is designed to suppot! protected RFC comnumication. 

Not all distributeti applications in a DCE enviromnent vtill 
use RPC. Most client/serv^er applications in existence today 
are message-based, and chajiging the in to use the RPC para- 
digm is expensive and tinic -consuming. It is also not practi- 
cal tor ceilain applicati(.)ns to use RPC. Tiiese applications 
nonetheless require seciuity For this reason the DCE secu- 
rity^ service now supports tite Generic Security Service API 
(GSS APD, vvhicit allows an at^pli cation to audienticate It self 
to a remote party and secme data for transmission over an 
arbitraiy communication niechtmism. 

Fom- basic* levels of protection ai'e available with either RPC 
or GSS i\PI: 

• No protection. The DCE security senice does not rnetliale 
or participate hi the connection, 

• AutJientication. Tlie user of the client application is airthen^ 
ticatetl to the server. 

• Data uitegrity. A cryptographic checksum is included with 
the data transmitted. The DC'E security service guai'antees 
the data received is identical to the data transmitted. 

• Data privacy The data is transmitted in an encn^^ted fonn 
and is therefore private to tlie sender and die receiver 
L'Uited States exijon regulations hmit the availablhiy of tlUs 
levei of protection outside of the United States aiui Canada. 

The higher protection levels hi elude the protections offered 
by the lower levels. 
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Securitj' beyond DCE 

LogiciiHy. two login sequences an? required: the login to the 
sy^^iem aiid the login to DCE, Entries in the DCE seciirit\- 
senice registrv^ contain all the atrrihuies associated with a 
UNIX account. These enities can be used instead of the 
traditional /etc/passwd file or NlSt database as the source of 
infomiafion for the UNIX system login. The HP-UX* operating 
s^rstem integrates the sy^teni and DCE login sequences into 
an integrated login faeilit>; which is described in the article 
on i>age 34, 

The DCE security senice can be used as the core security 
service for the enterprise becaiLse it features an extensible 
registry'' tlu'ough the ERA facility'. Products from HP mul 
other manufacturers Ucensing DCE from the Open Software 
Foundation (OSF) will undoubtedly use the extended regis- 
tr>^ attribute facilitj^ either lo provide other integrated iogin 
facihties or to syncliroiiize tlie DCE security senice registr>^ 
with other user databases. 

The secure data comnumication mechanisms described 
above can be useiJ by system vendors to secure the standaid 
network comniunication protocols, such as the file transfer 
protocol (ftp). 

Security Meehanisms 

The mechanisms used by the DCE securitj^ senice to pro- 
vide secure data conmumicarion are a combination of key 
distribution, data encryi>tion. and data hash tables. The pur- 
pose of this section is to give more details about these 
uieehanisms. Some details have been omitted for brevity 
and reatiability More fonnal and coniplete descriptions of 
the aigoriihrns can i.)e found in the references indicated 
below. 

Data Encryption, Tlie DCE security senice uses the Data 
EncryjiHon SuuuJard (DES)'^ algorithm to protect die data it 
transmits. This algorithtn is used by both HPC ku\d the GSS 
API to protect user data and guarantee its integrity EJES 
requin^s that the t^vo paities eKchaiiging infonnation share a 
secret key. wliich is only known lo tire r wo i>arties. l*hjs key 
is 64 bits long and has 56 bits of data and 8 bits of parity 

DES encrypts plain text in blocks of 64 bits. The encryption 
is <>l)tained by the iteration of a b<Lsic ojjeralion which com- 
bii\es [jerniutation of bits for both key and data with exclu- 
dve-OR o|)eralions- The result of tlu' enciyiirioii is a l>)ock of 
cipht^T (exi in whi( h entii bit depends cm all the bits of the 
key aiid the i>iaiti text. Decryption of ttie cipher text involves 
the inverse of the same basic operation. The party receiving 
the cipher text and performing the decryption has a copy of 
the key used for enroption. 

The DCE j^ecurity service uses DES in cipher-block-tthaining 
mode in which plain t*^xt blocks are exclusive-OReff with the 
pre%iotis Cipher text block before beuig enery]>led. The DCE 
security service also uses conlbiuwler data, whitii is a 
duHTmy block of rmidnm data placp^i lieforc the ai>j)lication 
data, Cojifounder data is used to prevent guessing by ror- 
n*Uiiion i>etween bli>cks of enciyiJted data. The s^uue ijlock 
of plum text can result in two completely different blocks of 
data once enciypted with the same key because of the fact 

iNIS. or I4etwari( jiformariori Seivjces, is b prnducT frarn Sun Mioosy-^iiflms. 



that the confounder data wiO be different. These tw^o tech- 
niques render seciuitj' attacks particularly difficult because 
each blcK'k of cipher text depends on the pre\ious cipher 
block and some random data, 

One-Wav Hash. Tlie DCE security ser\ice uses the message 
iligest 5 vMD5) algorithm^ coupled with the DES enciy^jtion 
dgoritlun to guarantee the integrit>^ of the data being trans- 
mitted and verify the success of the derr>ptJon oiieralions. 
MD5 produces a i2S-bii signature (also called a message 
digest) that represents the data being transmitted. This mes- 
sage digest is obtained by processing the data in blocks of 
512 bits. The algorithm is driven by a fixed table containing 
64 operations. It uses fotir 32-bit ^^ariables and involves rota- 
don, exclus3ve-0R, OR, negation, A NO, and addition operatioits 
on these ^Tuiables and the 16 32-bit segments contained in 
each block. like all one-way bash functions, MD5 is designed 
to be easy to compute and diffu ttit to break (i.e., deri% e 
plain text from a given hash), I>CE tises CClTT-:32 CRC,^ a 
c hecksimi algoritlim. to verify data uuegrity in certain cases. 

Keys. The DCE security service uses t^^o types of keys: long- 
term principal secret keys and conversation or session keys. 

• Piincipal keys. The DCE authentication protocol (described 
below) requires tltat the D(^E securitj^ ser\ er and the princi- 
pal i^eque sting anthenticatir>n share a secret key. For a ma- 
clnne or process principal, this key is stored m a file and is 
protected by die local ot>erai it^g syslem pnnection tnecha- 
nisms, hi the case of a human principal, the senet key is 
derived from the user^s password by a one-way hash func- 
iiot\^ All the principal keys are stored m the DCE registry* 

• C^onversation or session keys. Conversation tmd session 
keys ai'e used to enciy|it Ute data atid checksuitLs exchcU^ged 
between die application cUent , the application seivei; and 
the DCE security sender. Tlie designs of the DC E and Ker- 
beros set^urity mechanisms avtiid die need to establish a 
lonj^-t erni secret key for each f)air of communicating princi- 
I);ils by creatnig siion-Iived sessit^n keys and comnutni coat- 
ing them securely io earh jirint iiial engaging iri a data ex- 
change. In addition, ses.si(jn keys re(htce the vulneralnlity of 
long-term principal keys because the latter are used le.ss 
often and tlierefore are less susceptible tc> offhtie attac*ks. 

The conversation and session ke>^ are generateti as random 
numbers by iht* DCE security service and are not reused. 
These keys have typical Ufetimes measured in minuTes. 
Session keys are keys coimnunicated to i>rinciijals in lickets, 
whereas conversation keys ai-e established ciynamlc^dJy by 
the RPC nm-time en\ircmnien( to protect the data transmis- 
sion. Session keys are used in the cstabiislunent of commu- 
nication keys. 

Authentication Protocol 

Asiinplitletl illustration of the authentic^afion protocol is 
sliowa in Fig, 2, The circkMi numbers in this section coiTe- 
spond 10 the circled numbers in Fig. 2. 

At the start of a user login sequence the computer estab- 
lishes a sessii^n with the DCE security senice. The user's 
paasword is trat^sfomied into a secret key 1 . Tlie client 
system has a file ccmtaining a niachitie TOT and a ma<iiiue 
session key. Knowledge about tJie niachitte session kc*y and 
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Data item encrypted first wilh key x and then with key y. 
To get to the data item. I he leken must be decrypted in 
revere order [i.e.H first key y and then key x]. 



Fig. 2. ( Yentirhn of a Ticket -granii tig ticket (TGT) via the aiillieiitEcalion protacol,. 



tlie user secret key is shared between the client sysiem tuid 
tlie DCE server system (see keys a aii<l b in Fig. 2), 

Tl\e prolocoi ttsecl lor amhenti cation is kntn\Ti as the DCE 
tliiid-paity^ jn'^^^t^^i^^^tication proioctrl Ttie pixitocol starts 
with the DCE seciuity^ lit*raiy rectuesririg, on lietialftjt a login 
utility, a conversation key antl a iTiachiiie TGT froni the DCE 
daemon, deed 2 . Deed provides the first {conversation key 
and tlie machine TCiT along with a copy of the conversation 
key encrypted with tl\e machine session key i , Tlie secu- 
rity library then generates a token containing a time stamp 
and a second conversation key. Tlie libraiy encrypts tliat 



token t^-vlce: once wit it l lie key derivetl from tlie tiseri^ass- 
word and once witli I he flrsl conversation key i , This en- 
ciypted token is passetl to the DCE security scrv^er aJong 
wilh the macliine TGT and the encrypted convei"sation key 
received from tlie deed process Jj. 

Upon receipt of the token and other items, tlie DCE secitrity 
sender decr^^jts liie titst conversation key using the machine 
session key & , b ilien deciyfUs the token ct)iKaiimig the 
time stamp and ttie second con\'crsation key using ilie first 
conversation key ? , Next, tlie token ts decrypted tising the 
user's secret key storetl in il\e registr:^* database a . If tht^ 
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lime stamp is within acceptable limits, the IXrE securit>' 
server creates a token containing a TGT and a ctient session 
key 3 . The s<?cuiity server passes the token back to the 
cHeiit enenpted with the second conversation key i9 . The 
cliem decnpts the token, ^alklates its content, and stores 
the TGT ajtd the client session key in tlie login context for 
use in ftitHre requests for senice tickets CS) . 

At this point the user aiid the DCE si^'Uiity server are mutu- 
ally authenticated- Note that the user's secret key was never 
sent (in plain or ciphered formal) to tlie DCE sec:urity server 
Proof fiiat the user knows the correct pa*>sworci is verified 
by the fact tliat the thne sianip is successfully decodeil by 
the DCE security' server. 

Privilege Service, The TGT dest^ribed above does not contain 
ilu* iiifonuation necessaiy' ^or the advaitced authorization 
mpctimiLsms such as groups and ERAs. Tlie privilege service 
provides this infonnation by creating an EPAC and a privi- 
lege TGT whicti contains the TGT and a seal (checksum) of 
the EPAC. 

Wliea an authenticated RFC is attempted and a valid privi- 
lege TGT is not available, the privilege senice is cantactetl 
by the security- library. First I lie library obtains a service 
ticket ffjr the privilege service in a manner similar to what is 
described below, but using a TGT Instead of tiie privilege 
TGT 

The [privilege service then prepaies the extended privilege 
amibute ceitiUcate, creates the privilege TGT. and commu- 
nicates it back to the client. Application ser\*ers will be able 
I n request the EPAC thmugh the RPC run-tinte emlronmeitt. 

Secure Comttiunioatton. The authentication and kf^y exchange 
Ijrolucol needed to establish a secure coinnuinicatifjn chim- 
nel hf-twf en a i iieni and ils associafeti server is tnuisjiarent 
10 tlie api)UcatioiL Tiie RPC an(i GSS API facilities and the 
DCE security se-rvlce library cooperate in establishing a se- 
cure comniunicatitjn f^hanneL 

Fig. ■) Ls a sin^iJlifietlt reinesentation of tlie sequence of 
events for establisliing a prti(ected RPC rommnnication 
clmnnel. ;^samning a valid taivilege T( JT has ahcady been 
estalilislied by the privilege senice iis described above, Tlte 
circled numbers in ng. 3 corresijond to the circled ntmibers 
ill I ills s<MtiojL Pirst, the applit alion ciieiif niakes a rrt|uest 
I o 1 1 1 e M j II » 1 i cat i <>i i sen er ijy cai I i n g aj i R PC st 1 1 h i . 

Shue the appHeation client needs a service ticket to authen- 
tic^vte itself to die ajjplication serv er the seciuity libraiy 
generatx^s a request to get a ticket and a convei-sation key 
from the security serv'cr This results in the creation of a 
token containing the request for I he ticket and (he privilege 
TGT encr>i)ted by tlie client sessioti key leametl during t lie 
Uigin serinence. The token is sent to the key distribtition 
center (KDC ) vviiich is in the security senvr ^ . 

The KDC decry pis luid v"alidates the request and then gener- 
ates a conversation key for use between the application cli- 
ei^t and the apislitation server It encr>l>^^ l^tt^ i'tynversalion 
key ami the aulhenticatioii infonnalion (iii I he sen-ice 
ticket J with tlie secret key it shmes with the aiJt>llcation 
Signer 3 . It attaches another co])y of the convei'sation key 



to the service ticket and encrypts the whole structure vsith 
the client session key * . Tliis token is then sent to ihe ai>- 
plication client s^'Steni 5 , wliich decrypts tt and learns the 
conversation key T . 

RPC then enci>pts the RPC request with the conversation 

key i and sends it to the application server The application 
sen'er learris die lonversation key and checks tiie client "s 
authenticit>^ To accomphsh this, the application server 
sends a challenge, which is jtisi a random number s . The 
cUent receiv'es this challenge imd replies by sending a token 
containing the encrypted cliatlenge and the encjvpted senice 
ticket and ccanersation key obtained from the security^ 
senrer J , The sen'ej: deciypts the ticket and obtains the 
client privileges and tlie conversation key jo . h decrypts the 
challenge with this ct>in'ersation key ]\ , and if it matches 
what is sent, the authenticity of die dient is assimied. It then 
proceeds to decrypt the recjnest from the chent i? . Tlie c-lient 
and server now share a secret conversation key. 

Additioiial Functionality 

Extended Registry Attributes 

The DCE regiatiy contauis principal! account data in a well- 
defined format (i.e.. a static sclienia). Eveiy acr ount record 
contains tiie same number and types of data fields, all tar- 
geted to meet the requirements of either DCE seciuit^"^ or 
UNIX plalff>rin seciuiry To support integiation with other 
platforms and security systems, the DCE registry needed a 
way to store non-DCE or non-lt.\]X security data for princi- 
pals. To meet this need, the DCE registiy \^'as augmented 
witii a dy nan lie schema facility called tlie extended regis tiy 
attribute (ERA) facility which sut>poits the definition of 
new tyi^es of data fields called attribute types ^ukI the iLssigu- 
ment of specific vakies for t hose attribute types to prin<::ipaJs 
and other registiy c)l>jects like groups and organ tzat ions. 

In the ERA schema, admimstrators defme new attribute 
tyt>es by specifying a luiique attribute name (e.g.t X 50f]_Distin- 
guished_Nanie), the appropriate data t>pe ((' g^* siring), tiie 
type of registry object (e.g,, priu< iiuilj rhai suptKnts attril> 
utes of thistyiK\ and father related infonuation. Once Ihe 
attribute tyiDe has l>een detitU'd in the schema, an achiiinis- 
trator can Httacli an irtstcUice of that attribute r^^pe to imy 
regis! ty ol^Jeci that sup])Oi1s it. For examfile, ^^ui attril>ute 
Instance whose ty^^e isX.500_DFStmgLjished_Name lukI whose 
value is /C^US/o^HP/OU^OSSD/G-JOE/S^KiWG could be attached 
to the pjincipaJ Joe.tt From then on applications thai re- 
tiuire kriuwledge of Joes X.5l)0 distinguished name could 
<iuery the registry for that attribute tyiie on the principal 
4oe. 

In so!ne ceases, attribute values of a certain tyi^e are more 
appropriately created and maintained «,>utside t)f the DCE 
registiy These c ould inclufle aiuiijutes that are dready main- 
lainetl iti a preexisung h^gaey drilaijase or attributes whose 
values dilTer depending on (iiseriminating factoid such as time 
of day or operation to be invoked. The ERA trigger facility 
supports cases such as these by (jioviding an automatic trig- 
ger (or ealloiit) tn a remott^ trigger senet^ thai mainlaijis tlie 
Ml tributes of inUTcst. Eor example, if the registiy receives a 



■ In particulaf, the canvafsatiofi key is sstabltshod m mote 5tL>ps ttiari ^Mwu. and the gmaml j t See tN arride an page 23 for m\ ajepianation cf Ihe tieJds in this string. 
impE€CTM)is cazhit\Q su as not to requtrB ell steps to he unncunsA ewE?fv Uma. 
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Fig. 3. Selliiig up a secure coiuruunicalion betv^^een a client and ser\'"er, 

query for a particular attribute type thai is n\arked as a 
trigger, the reglstiy foi'waids the query to a prerontigiired 
trigger sender. Tlie sen-er ^vill retum the appropriate attrib- 
lUe value to the registry, which will then respoud to the orig- 
inal query witli thi^iv value. A quer>^ for a trigger attiibuie uiay 
include input data required by the trigger ser\^er to deter- 
mine the appropriate attribute value to return. Trigger serv- 
ers ai'e tiot proviiled tis part of the DCE package; rhey aie 
pro\1ded by third i) arty iutegrators of security systems. The 
ERA trigger faciLit>' provides the niles, uiterfaces, and oieeh- 
anisnis for integrating trigger senders with the DCE security 
service. 

Some apphcation sen ers need to make decisions, especially 
authoi'izatiou decisions, based on the calliiig piincipal's 
attribule viilues. Tlic DCE pmilege senice supports tliis by 
pro VI cling a way for applications to request that specific 
attributes be included in a principal's EPAC. As described 
earlier in the "klentiflcation and Authentication" section, the 
RPC niii-time enviromnent support^) queried) for oblcUning 



the calling principal's EPAC. This enables application serv- 
ers to base decisions on the caller's attribute values and tlie 
identity and gronpset hifonuation in the EPAC. 

Delegation 

hi a distributed environment^ an apphcation server process- 
ing a client request may have to make a request on Its own 
to ano tiler sei"VTr to complete the client request. We will call 
(he application seiver mth the request an inteimediate 
ser\-en The identitj^ reported by the uiterniediate serv er to 
tiie serv^er it contacts can be either its owti identitj^ or the 
idcntit;^ of the client fhat made tiie original request. Tliis 
latter case is (^alled delegation because the intermediate 
ser\ er acts as a delegate of the client. A delegatiori chain is 
built as iutennediatc senders call othei' intermediate servTrs.^ 

For delegation to be possible, the client lias to enable this 
feature explicitly. Two tyijes of delegation are available: 
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• Traced delegation in which the identity and privileges of 
each intermedial^' are kept and can be used for access 
control 

• Impersonation in which only the originator's identity and 
prHUeges are carried in the extended pri\11ege attribute 
certificate, 

ACLs have been extended to support delegation, making it 

possible to gmnt access based not only on the originator of 
the request^ but also on the intemiediaries. This allows ad- 
ministrators to grant access to senders acting as delegates 
on behalf of particular originators without granting access 
to tlie same sen-'ers operating on their o^ii behalf. 

Compatibility with Kerberos 

Tlie authentication service provided in the DCE security is 
derived from Kerberos version 5. ^ The protocol used be- 
tw^een a client and server using the DCE security senice is 
the native Kerberos protocol and has been adapted for RFC 
transport- 

DCE security' supports Kerberos version 5 clients (e.g., a 
telnet, or a ferminal serv'cr that uses Kerberos version 5). 
This removes the need to manage a sepaiate Kerberos realm 
because DCE security supports the registration and authen- 
tication of Kerberos princi]jtals. 

DCE security' also jirovides an API that can be used to pro- 
mote Kerberos credentials tliat have been forwarded to a 
DCE client into full DCE credentials. Full DCE credentials 
represent an authenticated DCE principal thereby enabling 
use of DCE services. 

Auditing 

DCE offers an auditing service that is part of DCE seciuity. 
The DCE secLuity and time ser\ices use audit i Fig to record 
security-relevant events like accoimt crealiQii. lieket grant- 
ing, and system time ctianges. 

DCE audi til ig is cfinl rolled by tlie DCE control progiTun, with 
which DCE athuinisti^tors ran select the events to audit anfl 
control the otjeraUon of the audit fiul>system. 

Authenticated RFC 

The DCE remote procedure call (RPC) facility is described 
in more detail In flip article on page 6. The RPC facihty is 
integrated witli ihv DCE security service and is refened to 
as the aul:henticated RPC run-time environment. 

When an application client wants to make a protected re- 
mote call, it calls the authenticated EPC run-time emiron- 
ment to select: 

• The authentication service, which can be either no authentic 
catifm or secret key authenlieatioji 

• The protection level, which specifies whether autheniica' 
tioii shtuild occur (jnly at the beginning of an RPC^ .session or 
at each message or packet and whether me.ssage tlata 
should be jntegrily or confidentially protected 

• The authorization senice, whicii can be name-based, in 
wliich case only the namt* of the caller is known to the 
server^ or pri%ilege'ljased, in which case all tiu* privileges of 
the clienl, in tlie form f>f an EFAC, tire made a\"iulable to the 
senvr for autluJrization. 



Hie application developer can trade off the resources con- 
sumed by an application with the level of security required. 

Generic Security Service API 

The GSS API improves application portabilit>^ by reducing 
security-mechanism-speciBc code, h also provides tran^fK>n 
independence since the data protection is not tied to a par- 
ticular communication mechanism (e.g.. DCE RPC). GSS 
AFl calls are used to authenticate and establish a security' 
context between commutiicating peers and to protect 
blocks of data cr>ptographical]y for transmission between 
them, T!"ie data protection includes data origin certification, 
integrity, and optionally, confidentiality* 

The GSS API supports many different underlying security 
mechanisms. The GSS API implementation pro\ided with 
DCE supports both the DCE and the Kerberos version -5 
mechanisms. 

Security Rtm-Tliive Environment 

Applications can access security fmictions directly through 
the security library, which is pan of the DCE library on the 
HP-UX operating system. The security library provides APIs 
to make access decisions based on ACLsj manage key tables, 
query and update registi^^ data, login ariti establish creden- 
tials, and so on. 

System administrators and users can use a series of com- 
mands to administer the security service or manage their 
local secmity resoiu'ces such as credentials* -\CLs. or key 
tables. Most of the administrative commands are part of the 
DCE control progran\. 

MulticeU Configurations 

hi large enter|>rise networks, it is often impractical or unde- 
sirable to configure a single cell. For this reason, DCE fea- 
tures intercell comiuunication niechmiisins. See the article 
tm page 6 for a brief description of cells. 

The DCE security service is an actor in this intercell envi- 
ronment, Through a mecluuiism of key exchange, a relation- 
ship of trust can be established betw^een two cells. When an 
application client wants to commmiicate with a server in a 
foreign cell, it niiist obtain a service ticket for that server To 
do so, the DC^E security ser\icc automat ically generates a 
foreign privilege TGT, which contains tht^ privilege infonua- 
tlon about the piincipal (application client) in its local cell 
enci>iited using the foreign cell's keys. This key, shared be- 
tween the two cells, is used to authenticate and secaire this 
protocol. The DCE security service then proceeds to get a 
senice ticket to t!ie foreign sender by ccmtacting the foreign 
autiicntication senice as it woukl do for the local cell by 
using tlie foreign jjrivilege Tf iT instead of the privilege TGT 
LLsed in the example given earlier. 

ACLssnpiHjrt the intercTll ot>erations by i.dUnving foiTign 
users, gnjuij.s, iuul otiiers to be grtuitetl pennissions. 

High Availability 

The DCE security service is an essential piece of the ilistrib- 
uted conijjuting cnvirnrnueiU. Thus, t\w security servite 
must stay operational around the clock even wliea systems 
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are dowTi or network coimections arc* iuia\-ailable, whicli 
could Imppen frequently in wide area network environments. 

For this purpt>se, tlie DC'E security service features a server 
replication mechanism. The master replica is the only one 
that can accept requests for n|>dates such as (lassword 
chajiges or account nioflifications. These niodillcatioi^s aie 
sent securely to slave rei)Ucas, which contain a duplicate 
image of the registry- database, hut support only queiy. not 
update operations. Tlie use of slave replicas improves per- 
fomituice in busy en\ironmenrs since additional DCE secu- 
lity sen.'ei*s ai*e avmlabie to process queries iintl requests for 
secure conununiration. 

The DCE security service administrative commands aUow 
the role of master to he moved be r ween replicas. In case tlw 
machine liosting die master is not a\'ailable for si>me time, 
the admmistrator can force a slave to become the master. 

Iji the rare case bi which no network connection is available 
to reach a DCE security senx^r the DCE seciuity loghi clit*nt 
win use a local cache of credentials that i\ave been granted 
recently tf) perfonu authenticatioji. Ih^wever, the credenthils 
usu^Uiy cannot be used b > tibtain service tickets. 

System Security Re inurements 

Tlie use of the DCE seciuity sendee alone does not guarantee 
a secure distributeri computing environiueiu. Tlie sccuiiiy 
service relies on protection featincs offered by the local 
operating system to store its data ajid credentials. 

Tlie sy.siems hosting a DCE security ser\Tr must be pro- 
tecleci from unauthorized access, Tliey should i>e placed in a 
secure area, sucli km a locked room, and be gi\'en the higliest 
security consideratit>n?^. bi i>anit.u]ur ceitain network ser- 
\lces should be disabled and a limib^ti rnnnber of users 
should be given access, TMs security' is required because the 
DCE security server holds the keys to all die principals in 
the enteqjrise. 

The systems hostmg the apjilication servers should also be 
managed vtith ciue, mainly to protect the enteqaiise data, 
w^hich is often not protected by the DC'E security' senice. 

Application clients do not need such stringent management 
guidelines. On multiuser systems, the user eu\ironment 
should be partitioned so that one user cannot steal the cre- 
dent ials t}[ iinothcr active user, which could lie done by 
reading the other user's credential files. 

The DCE se<'urity sei'vice does not guarantee that there aie 
\Wi undetected intiiidere m the system. It fjffei^ no protection 
if t lie prt.:fgiam used for logm has been modified to steal the 
password, saving it for future retrieval by an iotnider 



If a system other tliau one hosting a DCE security server is 
compromist^d. tinly the applicalion senei-s residing on that 
system atvd the users who performed a login on tJiat system 
during the period of compromise are affected. The ovei^all 
disiributeti comi>irtingenAiroument protected by the DCE 
secuiTty service is nor affecterl This is because tlie keys are 
known fjuly by the owner (server, machine, or apphcation) 
and the DCE security servers, and ibey are never conmimu- 
cated to a third paity. 

AcJkno w 1 edgme nts 

Tlie DCE seciuity senice was developed by Hewlett-I^ickai-d 
for the Open Software Fomulatiou as ptut of tiie f Jistiibuted 
Computing Environment project. The DCE security service 
finds its roots in th(^ Domain operatinj^ system, the Network 
Computing System (NCS). and the Athena projeci at the 
Massachusetts histitule of Technology', which created Ker- 
beros. 0\ ei^ the ye-eirs, mmiy different engineei-s antl manag- 
ers, to(j numerous to recognize by name, have worked on the 
product. Tiie DCE security ser\ ice continues to evolve as 
new sei\ ices are added t iirough the pi^estructiired i:echnolog,f' 
program vuider the auspices of tlte OSE 

The audioi-s would Uke to th^mk Sue Kline. Mike Kung, Sean 
MuUan, Joe Pato, Bill Souimerfeld, and Rob Sianzel for their 
contributions to this artkie. 
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An Evolution of DCE Authorization 
Services 



One of the strengths of the Open Software Foundation s Distributed 
Compyttng EnvimnmBnt is that it aflows deve topers to consider 
authentication, authorization, privacy, and integrity early in the design of a 
client/server appiication. The HP implementation evolves what DCE offers 
to make it easier for server developers to use. 

by Beborali L> CasweU 



In the Open Softw'are Foundation's Distributed Computing 
En\ironmeiit (DCE).^-^ scniees are provided by sener jjru- 
cesses, T\wy are accessed on behair of lusers by client ino- 
cesses often residing on a different computer, Serv'er*^ need 
a way to ascertain whether or not the user has a right to 
obtain the senice requeste<:l. For example, a banking senice 
accessed through an automated teller machuie has to have a 
way to know whether the requester is allowed to \\ithdraw 
money fiom the account. A medical patient record service 
has to be able to know both who you ai"e and what rights 
you should have with respect to a patient's recorci. A policy 
can be Imp i em cut ed such that only the patient or the legal 
guardiaii of the patient can read the record, but doctors and 
nurses can have read and write access to tlie record 

Tile process of determining whether or not a user has per- 
mission to pertbrm mi operation is called authorization. It is 
common to separate the authorization policy from the au- 
thorization mechanism, Authorization policy dit tates who 
lias ivennission to perform wtiich opt^mt ions on which ob- 
jects. The mechanism is the j^encral-pnn>ose code that en- 
forces whatever policy is specified. In DCE, the encoding of 
the authorizal ion policy is stored in im access control list 
(ACL). Ever>' object I hat is managed by a server such as a 
bank account or a patient record has associated with it an 
AC'L that dictates w hich clients can itivoke each operation 
defined for the object. 

For example, to encode the pohcy that the owner of the 
b^ui k at cm i t ^ t t *aT \ ( 1 ep o s it ^y id wit h c i ra w n i o n ey f rf j m 1 1 1 e 
account find change the mailing address on \\w act uuni. hut 



only a bank teller may close tlie account, an ACL on a bank 
account owned by t:lient Maiy niigiit look like: 

userMaryiOWM 
groyp:teller:C 

where □ stands for penmssion to deposit. W for permission 
to withdraw. M for permission to change the mailhig address, 
and C for i;)emiission to close the account. 

Each application is free to define and name its owii set of 
permissions. The D, W, and C penuissions used in I be exam- 
ple above are not used by every sen en An application in 
which the D (deposit) permission makes sense t:ould choose 
tti nmite it as Ihe **+** i>ennLssion. .Also, many ajj plications 
will not ha%e a deposit o| aeration at all. Therefore, the mter- 
pretaticin of mi ACL depends on the set of [lermLssions de- 
fined by the sender that uses it 

The first part of this paper describes the specifications m\(\ 
authorization mechanisms (code J offered itt DCE ihat sup- 
port the development of authorization sen'l(i:^s. The second 
pait describes (Hu- efforts to supplenunn what DCE offers to 
make it easier for the ser^^er ileveloper to use authorization 
senices. The ACL functionality descritje*! here pertains to 
DCE releases befon- OSF DCE LI and Hl^ IHT: LI. 

Auth0rkatio]i Based on Access Control Lists 

Fitj. I shows ilu* clicMn/sener modtHes required for an ACL 
authorization scluHue used ii\ a hypothetieal Ijank apptica- 
tion that was intplenienteci iisirig DCE. To underst*uul the 
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interactions between these modules consider the following 
sccnaiio, Jane makes a request to ^^ithciraw U.S. SIOO.OO 
from her account number 123 1. The application interface 
passes this information to the ACL manager asking for an 
autliorization decision. The ACL manager retrieves the au- 
thorization policy for account 1234 from the ACL database 
and applies the policy to derive an answei; If Jane is autho- 
rized, the machine dispenses the money. 

When Jane's account is first set up, a bank employee would 
use an administi-ation tool (from the management process in 
Hg. 1) to give Jane permission to \\adidraw^ money from 
accoimt 1234. Tlie ecUting interface enables die AC L manager 
to change the policy. The ACL manager changes a policy by 
retrievmg the current policy^ modifying it, and writing it 
back to the ACL database. 

ACL Database. A sender that needs to authorize requests must 
have a w^ay to store and retrieve the ACLs that describe the 
access rights to the objects die sen^er manages. One appli- 
cation mi gilt W'ant to store ACLs widi the objects they pro- 
tect and another might want a separate ACL database. 
Depending on the number of objects protected and access 
patterns^ different database implementations w^ould be opti- 
mal Per tliis reason, the requirements for an ACL storage 
system are likely to be very dependent on the type of 
application. 

An Authorization Decision- TOien an application client makes 
a reciuest of the application serv^er, control is given to the 
manager routine Qiat implements the desired operation. The 
manager routine needs to know what set of permissions or 
access rights the client must possess before servicing the 
request. 

The ntanager routine must supply the client's identity (Jane), 
the name of the protected object (Accoimt 1234), and the 
desired pennissions (withdraw) to a routine that executes 
the standard ACL aut horizaiion algorithm. If the routine 
returns a positive result, die server will grant the client s 
request (dispense U.S. $100). Note that the authorization 
system depends on the validity of the client's identity. 
Authentication is a necessary prerequisite for authorization 
to be meaningful. 

Standard Interlace for Editing. Without a standard way of ad- 
ministeilng ACLs, each serv^er developer w ould have to pro- 
vide an ACL adnunisiration tool, and DCE administratoi'S 
would have to learn a different tool for each sener that uses 
authorization, To avoid that problem, a standtud ACL editing 
mterface is defined so that the same tool can interact with 
any semce that implements the standard iiTterface. 

What DCE Pro\ides 

To meet the requirements for the ACL management scheme 
meniioned above, DCE proiides code to support ACL 
management for some requirements and simply defmes a 
standard interface v^ithout pro\1diiig any code for other 
requirements. Fig. 2 shows the main components that pro- 
vide DCE ACL support within the serv^er executable. 

Unforgeabie Identities. DCE provides the nin-time RPC (re- 
mote procedure call) mechanism, wi^ich pro\1des the sen^^er 
process widi infoiTnation about the client making a request. 
Because of the autlientication sendees provided ii^ DCE, the 



Application 
InierfacG Stub 



From 
acl edit 




From 

A|ipli cation 
CJi«[it 



ACL Oiilab^se Acci»s Routines 

Fur ACi Storage aiift R^lrtmral 

ts.§;, sec ad i^t\ 




Access Dctitrol 
Database 



I ; Code tbai is automalicatfy generaied from the interface specEficaticn. 

H Code that must be provided by the server ctevolopcrs. These routines are 
embodied in the AQL manager in Fig, 1h 

Fig. 2. CiunipuuenlH Lhat provide DCE ACL aupport in a sender 
execuiabie. 

client's identity is unforgeabie so that the server need not 
worry about an imposton 

ACL Database. DCE suggests an interface to an ACL storage 
and retrieval subsysteni called sec_acl_mgr. This intertace is 
used within the server, and therefore is not mandatory or 
enforceable. DCE currently does not provide an implemen- 
tation oi' this interlace for use by application developers. 
Fiuthermore, il does uoi contain operations for adding and 
deleting ACLs, so even if rhe sBc_acl_rngr interface is used, it 
would have to be supplemented by other ACL database 
access operations. 

Authorization Decisions. FJCE specifies a standard way of 
reaching an authorization decision given a clients identity, 
desired operation, and authoiizarion policy encoding. Tlie 
OSF DCE 1.0 distiibution for apiD heat ion de^ elopers does 
not supply an implementation of this algorithm, lequiring 
the sender developer to wvile the authorization algorithm. 

Standard Editing Interface. DCE provides a tool called acLedit 
that an admunstrator can use to change the authorization 
policy used by m\v sener that implements the standard rdacl 
interface even though each sen'er might use a different set 
of permissions. 

DCE defines the standard rdaci interface responsible for 
enabling modification of the authorization policy. The rdacl 
interface is used by a c Led it to access and modif>^ ACL infor- 
mation. DCE does not provide an implementation of tlic rdaci 
interface. Without additional help from other sources, each 
ser^^er developer has to write rdacl routines lhat call the ACL 
database access routines. Sen^ei"s that implement the riiac! 
mterface can be administered by any cUent that uses t lie 
standard interface including the acLedii tool mentioned 
above. 
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The rdac* interface does not support adding and deleting 
ACLs; it only addresses edititig existing ACLs. For tliat 
reasoa an ACL storage subsystem must be designed and 
implemented for an application Uiat supports adding, 
modi^^g, retrjevmg* and deleting ACLs. 

The rdacl operations listed below art^ described in the DTE 
reference manual.'^ They are listed hert^ to gi^•e an idea of 
the size and fimctiunallty of die interface. 

• fdacl_gel_acc§ss: lists the permLssioiis granted lo a principa] 
lo operate on a piiitjcuiar object 

• rd3cl_ge!_mana9ef_typBs: gets the list of databases in which the 
ACL resides 

• rd3cUget_pfinistrmg: gets the user description for each 
pemiission 

• rd3cl_gat_referral: gels a reference to the primary update site 

• rdacLlookup: gels the ACL for an object 

• rdicLrspface: replaces the ACL for an object 

• rdacLtest_acE^ess: reuuTis true if the principal is authorize<l to 
perfomi the specified operation on an object 

• rdacljest_access_on_behalf: rettuns true if both the caller and 
a specified third-pait^^ principal are auihorized to perform 
the specified operation on an objecL 

An implementation of these operations has to call the re- 
trieve anfl modify operations of the ACL storage subsystem, 
invoke the authorization decision routine, and describe the 
permissions that are used in the ACLs for the particular 
implementation. 

Component Relationships. Some of the boxes in Fig, 2 
represent code that is automatically generated from iJie 
interface des<:ription, and other boxes represent code that 
must be supplied by seiver developers. 

The modules on tiie right side of the block diagram in Pig. 2 
rei>resent tbe application-specific interfaces and t*o<ie. Tiie 
application interface stub is the code gemmated i)y the Inier- 
face Definition Language (IDL) compiler when given the 
application interface files. For example, if we have a hmxk 
account serv-er, the apiilicntirm interface stuiis would re- 
ceive the call imd direct it lo (lie aiiplication manager. The 
application managers m-e the modules that implement the 
application server functionality. In our bank ex*imple, this is 
tlie code that implcnK*nts the deposit and wiihdjawal 
operations. 

On the left side of Fig. 2 is the code that is specific lo ACL 
management <jf ilie DCE standmd rdaci interface. The rdaclif 
f rdacl interface file) sender stubs are generated by running 
the IDL compiler over the rdaclifJdJ file which is delivercnJ 
with the DCE t>r<Jdiict. Tlie rdacl routines implement tlie op- 
erations tlefmed in the rdacl interface. The bottom nf Fig, 2 
shows the ACL storage and retrieval code. Tlie rdacl routines 
make calls to the storage layer either to get the ACl^ that 
will l>e sent over the wire to a requesting client or to replace 
a new ACL received from an ACL administration tool. The 
datalmse access routines must also imj.>leineni \\\t} siandaid 
ACL clu^cking authtnization algoritlun and a routine lo com- 
pute th€' cfTective pennissioas of a client with respect to a 
specific object. Tlie appUcation managers call tlie database 
access layer to get mi aulbfyrimtion derision. For exanifjle, 
the code that implements the withdrawal fjperation needs to 
first make sure that the client making the request is autho- 
rized to w ithdraw money from a particttlar account. 



Although they do not interact directly with each other, the 
appfication manner routines and rdacl routines coexist 
within liie same process and caU common ACL manager 
routtnes. 

Sttnunajy 

DCE supports a server process s abiiit>^ to make an autho- 
rization decision in se^^ral ways, but as shown in Fig. 2. 
there is a lot of code left for the sener de\'eloper to WTite. 
S*>me of the required code, sxich as the authoiization deci- 
sion routme, can be reused in other applications because it 
is application independenL Other code, such as the storage 
subsystenv is more applicarion-specific and might have to 
be developed for each new senice. 

Help for the Server Developer 

Tliis section describej^ lliree evolutionary steps that w^e took 
to supplement DCE s authorization support. The approach 
we took to each step is not novel. Each approach has value 
by itself in addition to being a stepping stone to a more 
sophisticated approach. 

Note that although the outputs from each of these steps did 
not directly become products. the>' did form the basis for HP 
Object-Oriented DCE (HP OODCE ). HP OODCE is briefly 
described later in this article and completely described in 
the article on page 55. 

Sample Applicatioris. The tlrst step w^as simply to pro\ide an 
example of server code that performs ACL m^magement. 
The application acLmanager is one of a set of sample appUca- 
lion.s written to demonstrate the use of various DCE facih- 
ties. These sample appUcations are a valuable learning tool 
and are also useful for cutting and pasting working code into 
a real- world application. 

The acLmanager is based on the ACL manager reference im- 
plementation distributed with DCE source ctjde. The smnple 
appiicatifJU uses a static table of ACLs, and there is no oper- 
atioi^ for atkling or deleting ACLs and no general storage 
manager. However, a c Ltd it can interact with this primitive 
ACL manager lo view or modify thc» ACL for one of these 
static objects . 

The acLmanager includes a description of how to tailor the 
code to one s own ai)iiIication ser\^er mid pro\ides more 
background on how ACL management worlcs than is a%'ail- 
able in the DCE manual set. 

Another sample appUcation, the phone database, demon- 
strates the use of an ACL manager insifle im api^lication. 
This more complex sample at>piication tiemonstratcs how 
appht alion interfaces mul ihe .ACL management Interface 
coexist within die sajiic sen er and how they interact. The 
phone database appUcation uses an in-nienioiy binary tree 
storage facUit^' with a simple checlqioint facility for commit- 
ting f hanges i:o stable storage. The persistent representation 
of ACLs can be modified by an editor for bulk input. At 
startup, the server parses and interiJrt^ts this file. 

As mentioned before, in additi<:>n to being a valuable learn- 
ing too It tiie sample appUcations provide reuse of code and 
idetLS at the source-code level 

Common ACL Management Module Interface. Cutting a sami^le 

apjjIiralMH] and tuLstin^ il lEiln a iiev\ aj>() Ural ion with ail 
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understanding of how it needs lo be modified m surely bet- 
ter tiiaii starting front scratch* Reiise through a code iihrai:^' 
is tietter yet. The pn>!)iem wa.s how to provide a single li- 
Iji'iU^ For ACL in an age ni en t when so nnirli of il is applica- 
tion-specilkv There is so muesli llexibiiily in 1m >w ACLs are 
managed. We wondered if it were possible lo anticipate 
what most developers would need and if we would be able 
to satisfy those needs by creating a general -jjurpose hbraiy. 

The fim task was to t>artttion the aspects of ACL iniumge- 
meni into ihose rhai are aptihcauon'St^ecinc and those that 
a TO appiicatiDn hir|p|>pndent The apphcafion independent 
portion would be provided as hbraiy routines. Our a]it:jroach 
to the application-speciiic portions w^as thieefold: 

• Lhnit tlte flexibility l)y providing routmes dial would be suf- 
fieieiil for most devidotiers. For example, although DlE 
allows a server to implement more than 32 penuissions, 
limiting support to 32 or less simplified tlie design 
considerably, 

■ Parameterize routines such that theu' behaT^ior can be deter- 
mhied when the libraiy is initialized at staitnp. For exam- 
pie, each application defines its own set of permissions. A 
table of i>ermissions can be downloaded huo the libiaty 
ratJier tl i at 1 1 lard <'ih I ec I i nl o 1 1 1 e 1 i l.> raiy ro ulin es . 

* Identiiy a well-deriued interface to the storage aud retrieval 
routines. M ntenti(«ied earlier, I he storage requirements are 
the one aspect of ACL management that will var>' the most 
among applications. By paiTitioning the functionality in this 
way, customers with sjieciiil storage neefls can write iheir 
own ACL storage managemeut. and provided that they roiv 
form to the published interface guidelines, would still be 
able to use the library for otlier ACL management hmctious. 

Fig. 3 shows a different %iew of the ACL components de- 
picted m Fig. 2. The api>lication server component is not 
called out setjarateiy iu Fig, 2. The sener initializatioii rode 
fserverc) is t>7>ically located in this component. Tlie apjjlica- 
lioii senei^ also contains the code that directs the DCE run- 
time code to start listening for incoming client requests. 

The appheation niiuiager component in Fig. 3 contains tlie 
same functionaUty as the application mmiagtn' component 
shown in Pig. 2. 

The ACL manager component m Fig. 3 represents the code 
needed to suppojl Ihe rdaci interface, tlie ACL checking algo- 
rithm, the computing of effective permissiojis, and other 
general utilities. Basically, tlte ACL manager contains iiD the 
ACL code that is independent of how an ACL is stored 



within a database. It also encapsulates the implementation 
of the ACL stmcture itself. In other words, if the data struc- 
ture that represents an ACL were to change, only the AC'L 
manager compcjnent woidd neetl to be re writ ten to accom- 
modate the changes. 

Tlie ACL storage manager contains the ACL database access 
routines aatd tlie At L fiauibase. The ACL storage manager 
can manage ACL storage in memory, on disk, or a hybrid of 
the two, 

Tlie circled uumbeiii in Fig. 3 con pspond to the folio^sing 
intc^ractions between ACL manager components. 

L The application server must call the ACL manager to ini- 
tialize its internal data stnictures and to dovtiUoad applica- 
tion-specifjc infonnatjon such as jieniiission jirint strings 
aird reference monitor t^allback functions. The reference 
monitor implements a general security policy that screens 
incoming retjuesrs based on the cHienJ s identity and the au- 
tJientication or autliorization policies it is using. The moni- 
tor does not base an authorization decision on the reqtiesteil 
operation or the tai^get object. The ACL manager performs 
that job. A default reference monitor is pro\iried by the ACL 
manager. If an at^plication has its own reference monito!\ it 
will be invrjked instead of the default monitor supplied with 
die ACL nuuiager. 

2. The appheation serv er must call tlie A(^L storage manager 
to allow it to initialize itself. The initialization eaOs perfonned 
by the ajipliration server are only dcsne once when the whole 
system is inii iiilized. 

3. The application manager calls die ACL manager to per- 
form an authorization decision or to invoke a general ACL 
utility. 

4. The application manager calls the ACL storage matiager 
TO add a new ACL to the database or to delete an old ACL 
from the database. 

5. The ACL manager calls tiie ACL storage maiuiger to trans- 
fer an ACL to or from the database in response to rdaci 
requests commg from acLedit. 

6. The ACL storage manager calls the ACL manager utility' 
routines to manipulate ACL data structures. One manipula- 
tion operatioti invoht^s cfinvening j)ermissionsfrom human 
readable fonii into a liitmap and \ ice versa. 
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7, Tlie ACL manager must make a calllMick to an application- 
specific reference monitor routine to stTeen an incoming 
rdaci request according to the appUcalion s genera] security 

policy. 

T\w goal for the common ACL management module interiaf^e 

was to explore appropriaie progranmiatir iiii erf aces, C>iu- 
implementation was a proof of the concept for tiie design 
and was not inten<!ed to be the best ACL manager package. 
Tlie implementation i>rov1(ied tht* same ftmctionaiity as the 
sample application except that it used an in-memorj^ binai^' 
tree to allow- applicarions to add A(^Ls at nin time- Ttte main 
contrihution of the common ACL management miHinle inier- 
fac-e front an application developer's standpoint Is ttie ability 
to link with a geneml-pnrpose Ubraiy rather than cutting and 
pasting som'ce code. The application developer can use 
liigher-level interfaces for creating ACLs mid get authoriza- 
tion decisions without haviiig ro understand aiul viTite the 
I mderlying mechiuiisiai- 

Although the conuiion ACL management module interface 
was nes er sold as an HP product, it w as useful in several 
ways. First, we letuned a great deal about ACL management 
aiui what developers would want to bt^able tt) d<» with it. 
Second, we used Ibe motluJes in an iurenial DCE tiiiining 
class that allowed us to leach ACL majiagement concepts 
and hfive the studeJiti? acid ACL majiagemem to an applica- 
'fion iiiey develt>ped during a tv\ o-to-three-hom" laboratoiy 
exert ise. Tlie common AC^L management module intcifacc 
allowt^tl the students to spend their lab dnu^ reinforcing the 
concepts presented in the lecture rather than getting bogged 
down HI writing a lot of suppoiling code just to make their 
appht-ation work Tlie experieiu'es of t lie chtss reinrorced 
our belief that it is possible lo sn import aptJlication develop- 
ers in die creation of ACL management functianality without 
every developer having to understand all of the complicated 
details of ACL management that are DC E-t prescribed but not 
at)plitation-spe(4fic. 

Hie version of fJCE provided by OSF only supports C pro- 
gram rtiatit^ interfaces. It made sense to implement die c*>m- 
mon ACL miuiagement modules in C for two rc^asons: 

• Since we were layering oti lop of D(!*E, it was more conve- 
nient to use the ^upfKjrted lajiguage, 

• Weexpericil dial nsets of the commtm ACL management 
modules wuniUl nlsa be t>rogramnting in C, and so would 
mini C interfaces lo the conun<jn ACL management modnlc 
inlerlart^ libraty. 

However, there is growing interest in C++ interfaces to DCE 
as well as su|>pn!i lor object-oriented progranmiing. In 
response to that nei*ci a C++ class librar>" for DVE called 
OODCE (object-oriented DCE) has been developed. 

IIP OODCE: A C++ Class Library for DCE 

riic common mmiagement module hiterface acted as a 
sfjringboard for design and i m pie mej nation of the (*++ ACL 
management classes which are pait of HP*s OOD(*E 
pro<Inct. Since it is much easier to create al)slraf't infc^rface 
delliiititins ui C++ than in C. these DCFl At L uianagcrncni 
clrLssi^s make it easier to provide access control vvitliin a 
I XT'] Mcrven Application developers am reimplc^meiU spe- 
cific classics lo customize the A(*L manager to fil !.heir 
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Fig. 4. HP t n >l)CE ACL management c tasn intt^^rn^htionships. 

needs. The classes supphed with OODCE anti lh(>ir intenela- 
tionships are shfiwn Ln Fig. 4. The classes showm in Fig. 4 
represem funher mudiilarizalion of the ACL manager mid 
ACL storage miuiager compf.nients shown in Fig. A. 

Class Descriptions. Tlie DCEAclMgr class implements the filacl 
intertace for use by the acLedit tool and other managenient 
toots. There is one instance of an DCEAciiyigr per api>li«"ation 
server The DCEAclStorageManager manages all AC L databases 
for this sener. The DCEAclStor age Manager is responsible for 
finding the database m which the ACL is stored and return- 
ing a handle to that database. Programs invoke the DCEAcl- 
StorageMansger hiterface to ci^eate or register a new^ ACL 
database and to access exisiing ones. 

The DCEAclDS class defines the interface to bxi ACL database. 
An A( -L database may delhic mi]!tii)lc ;i2-t>it wonls of per- 
missir?ns. The inteiprctation oi the pennission bits is stored 
in a DCEAclSchema object, and eacii databas*^ has exactly one 
OCEAclSchetna associated with it. 

Tlie DCEAcl class defines an interface for accessing UCE ACL 
inlbnnatitme hi adtlition to the DCE ACL infonnation, the 
OCEAcI class contain.^ informatinn about thi' database irt which 
it resides, tJie owiht imd gronft of the p rot cm 'led (^bjccu and 
other infomiation that is needed by an imt>lementation. The 
DCEAcl s slate is read-(mly. The DCEModityabfeAct t^ass is a 
nuKli Habit* version r j1 the OCEAct class. 

Using the OODCE ACL Management Classes. The application 
scr\t'r invokes a simi^lc macro that iiviliali^^cs the .^CL sys- 
tem. Ot )DCE, by default, himdles £l11 the iletails of makutg 
tite rdacl interface ready to be invoked by rentote ctients. 
This ijicludes registering the interface with die fiF'C nm4mie 
routin€*s so that an mcoming rtniuest foi^ tliai intc^rfacc is 
received and ensuring that the coned entr>' point fcu" the 
rdacj routines is invoked. The applicai ion Si^rver also handles 
expf>rting Ich atif^n infonnation U) thecndtHJtnt mapjjert and 
CDS (cell dirt*ctor\f semce) databjisc sc> fhaf rlii^nts cmi find 
the servers ACL manag<*ment interfact\ Hiat is the r>nly 
required involvement of the apjihcation Hcr\ er. However, the 
applicatiijn server may create DCEAclDb objt^cts that can be 
slu'U"ed across mmiager objects. These databases nuist be* 
regi.st eiec I w i I h I lu * D C E Ac IStor a g e M a n ag e r. 

t The mappfiT mslniams a tisr of interfaces anrt the correspandirig part numbeis wheie ssrvicas 

of the Emerfacas bib liilenincj. 
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Application niajiagers create new ACL objects by first re- 
questing the DCEAclOb objecl to create a DCEModifyablfiAcl ol>- 
ject and adding ACL entries t<j it. UTien done, the DCEModEfy- 
ableAct object is committed (added) to tlie datal:>ase. To get 
an authorization decision, an application manager retiieves 
an ACL object from the database ajtd interacts mih k to get 
an authorization decision. 

Overall, it is easier for I he applicalion developer to use the 
OODCE ACL manager elas.ses Ihan any of the preiious 
soluUons. Many of lite routine t^isl<?5 are done by default by 
the library, hnt they cm\ he overridden iftiifii- are special 
circunistanccs. The ACL management objerts are written to 
ihe abstract cliiss definition so that usei^ can provide liieii' 
own impiemt^ntaiions of DCEAclDb, DCEAcL and DCEModifyahie- 
Acl classes aiKi have them plug into the rest of the sysienr 

A DCEAcIDh implententation encapsulates the database ac- 
cess, ^riiis allows the flexibility of stoiing ACLs either with 
the objects managed by the sender or in souie other data- 
base. Any conmierciai tlatabase product can be used. The 
server developer need only implement DCEAclDb so that it 
conforms to the abstract interface aoti makes tlie calls to 
the conimercial database of choice. 

The DCEModifyablBAcI class allows for fme-grained editing, the 
rdacl inleiface only stippons Uie aloniic replacement of aii 
entire x^CL, whereas the DCEModifyabieAcI design supports 
(hanging indi\1dual elements lAithin an ACL* 

IIP OODCE ACL objects are more general-pun^ose th^in the 
common ACL management module inieriace described ear- 
lier because the abstiact class design of HP OODCE accom- 
modates more features. Its design sup|>oris more than *J2 
permissions, and registration of the rdacl interface with CDS 
and the endpoint ma]3per is automatic and traj^sparent to 
the sen er developer. 



Current Status. HP OODCE is now a product. It includes de- 
fault implementa!i<jns for all the classes, but we expect that 
customers will write dteir owti implementations of DCEAclDb 
and possibly of DCEAcI and DCEModifyabieAcI. There is stiU 
much to leam about i^hat distributed application developers 
really need from an ACL management trackage, but with the 
HP OODCE library as a product, we have more opportunity 
to get feed I jack- HP OODCE is described in more detail in 
rlieariir!e<mpage5i>. 
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An Object-Oriented Application 
Framework for DCE-Based Systems 

Using the Interface Definition Language compiler and the C-f+ class 
libra FY, the HP OQDCE product provides objects and abstractions that 
support the DCE mode! and facilitate the development of object-oriented 
distributed applications. 
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HP s Object-Oriented DCE (IIP OODCE) pro\i(iFs a librai^^ 
of framework and uLilily C++ classes that hide DCE pro- 
granunatic complexity from developers and provide auto- 
matic default behavior to ease the development of distrib- 
uted appiicalions. The defauil behavior is also a great help 
in shortening application development time. HP OODCE 
offers nexibUity by allov\ing developers to use subclassing 
and cu-Stoinizefi implementation. Fig. 1 shows the protJucl 
structure for HP OODCE. 

HP OODCE allo^^^s clients to view remote objects as C++ 
olyects m\(\ lo access member functions and receive resuks 
without making explicit remote procedure calls ( RPCs), 
Also, applications can communicate with each ot her using 
interfaces specified ti.v the Inlerfac e Definirion Language 
(IDL). FinaUy, HP OODCE uses the C++ class lihi-an^^ and the 
IDL compiler (idl++ ) to create an object-oriented program- 
ming environment that support-s RPC-based communicadons, 
clientysen^er classes. POSIX threads, and access to die DCE 
naming and security senic^es. 
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idl++-Generated Classes 

The idK+ < nmpiler takes an IDL specificatiot\ like the one 
shown in Fig, 2 and generates the C++ classes shown in 
Fig, 3, Tlio idi++ compiler also generates the header file and 
stubs normally produced by the DCE IDL compiien 

Tlie concrete client class* describes the client proxy object 
that accesses remote C++ objects implemented by the 
server. The proxy object gives the client the impression that 
the instantiation of a pailicuUu' server object is executing 
locally. Fig. 1 shows an exam[>le of a client prox>^ class dec- 
laration for an interface to the Sleep function, which is re- 
sponsible for putting a process to sleep. This class contains 
multiple constructors that, when called, locate the compat- 
il jle manag<*r (st^rver) objects based on location infonnation 
ai\d the lU'ID (universal unique identifier) supplied as argu- 
nients to the conslructoi's. 

The abstract server class in Fig. 3 provides declarations for 
member functions defmed in the IDL specification that 
correspoufl to reincjte operations that can be accessed by 
the clietU proxy i>bject. The default concrete sener class 
dt*fiares the member functions specified in Ihc^ alisUiKi 
class. The functions must bv implemenicd by the apijiicatitjn 
develoi>er. Fig. 5 shows tiie ab strati and c^oncrete server 
manager deelaraUons for the Sleep function. 

The entiy point vector contains entry points for each remote 
procedure defined in the IDL specification. 

HP OODCE Ser\er and CUeiit Classes 

The serv^er code that interatis with the DCE subsystems is 
embodied in the DCEServer class. .An in.sranceof the DCEServer 
class, called theServer, manages the renu>te objects that ai e 
exported by the DCE server application. Tliese objects are 



//IgQJdl 

[uuiit(OOFCDD70'7DCB-t1CB-BI>DD-OSaO0?2l}E4CC|. 
versionOflil 
interfuce sleeper 
{ 

(Idempoienij void Sleep 
i (in) haridb.t h 

li^Itong iimet. 
] 



Fig. L HP UODCE prodijt 1 stri 



If iiirc 



Fig, 2, II IL stiecificatjon for the int'Tfare Sleep. 
' See ginasarv on pagE 60 loi a brr&l deEcnptiofi erf the C+^ termJnolDgy used tn ^f% arficle 
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Fig. 3, Hie files creatpci after an 
II')]* s(.i(if;ifica1 ioji is processed by 



irtstanres of Llie concrete sender manager cliasses and each 
has a Dt'E UUID. There is one DCEServer insiance per DCE 
rpc_sBrver_ listen call (currently per UNIX* process j, which 
starts tlie server*s run-time hstening for incoming RPC re- 
quests. DCEServer him member functiony lhi\t establish poli- 
cies such as object registration witli I he RPC nuvtime pro- 
cess or the nartung scnice and setiuig security preferences. 
Object registratiou Uikcs place whenever (he DCEServer class 
method RegisterObiect is calleti. Fig. 6 shows tlie seiver main 
program for the Sleep object and the implementation of the 
Sleep function. 

In HP OODCE, server objects are accessed via a clienl ob- 
ject (see Fig. 7). The client RFC request specifies a binciing 
handle that locates tlie interface and the DCE object IJUIlJ. 
The entry point \'ector code locates the correct instance of 
the requested manager object Fig. 8 shows the TIP OODCE 
clienl/sei'v^er iiin-tinie organjzali<3n. 

The idl-h-F-generated client proxy chiss has methods corre^ 
spending to the opera! ioris defined m the IDL specification. 
Idl++ jjrovides an hnplemeniation of the client proxy object 
methods. These methods locate the server and call the cor- 
responding C ++ stub generated by the idi++ compiler. The 
proxy imt>lementation handles rebindtitg, sets security pref- 
erences, aiid maps DCE exceptions returned by RPC into 
C++ exceptions (described below). 



class sleeper 1 0: publiD DCEIniarface{ 

sleeper 1 0(£>CEUiiidS> ta ^ NullUiiid]: 

DCEInterfacelsleeper vl D_c_ifspec. to) {} 
slee|ier_1_0(rpc_binrjing_handle t bh, DCEUuid& tii ^ NuMltuiil} : 

DCEInierfaceUleeper_v1_0_c_ifspEc. bh. to) { } 
sleep&r_l_D(rpc_ bin ding veclor_t*' bvec}: 

0CEInterf3ce|5leeper_v1_fl_e_ifspet, bvec) { 1 
5leeper_1_Q{ynsigned char* name, 

uns3gned32 syntax = rpc c_ns_syiitaj(_defBylt 
DCEIiuid&lo=^Nu3ILiuid): 

DCElntcrlaceEstBepEr vl c ifspec.na.e. syntax Jo)!} 
sleeper t Olunsignedchar* aetaddr, 

unsisnett cbar protseq, DCEUuid& to ^ NuHUuid! : 

DCEInierfaDB(sJeeper_v1_D_c if spec, neiadiir, protseq. Id}{ } 
sleeper 1 0(DCEOhiReff* refj: 

D C Elnterf ac ef si ee per tf 1 €_c_ifsfi ec, ref | { } 

// Mernber funciiens for client 
voiit Sleepl 

r [in] */ idLlofig Jnt time 

); 

); 

Fig, 4. Client \jmxy class declamtion. The class nontains several 
con struct urs for the* Sleep fLinttioiL The highlighted constryctpr is 
the otse used in the exarniiles in this article. 



HP OODC'E Framework and Utility Classes 

The framework classes represent Ihe HP OODCE rjlTJeci 
model abstraction and provide the basis for DCE liuuiional- 
ity and default behavior (see Fig. 9). Classes, such as DCE- 
Server, DCElnterfaceMgr, and DCEInterfacs Inieract with DCK 
ihrougl^ the DCE application programming interfat^e, 

Tlie idl++-generated manager classes (serv'^er side) inherit 
from the OCEObj and DCElnterfaceMgr classes. OCEObj associates 
a C++ object instance, which niay export several IKE uiter- 
faces, with a specific DCE object. Each DCE oljject Is identi- 
fied by its object LTTD. DCEObj holds the I'lIID Un tlie DCE 
object (see Fi^. 5b}. 



class sEeeper_1_D_ABS : pubtic: virtual DCEQh), DCEfniertaceMgrf 
public; 
// Ctass constructers must initialise virtual base classes 
£leeper_1_0_ABSjuuidJ* otij, uyi(i*tvpe); 
DCEObj(objK 

DCElRterfaceftflgr(sleeper.v1 J..S Jfspec. |DCEObja)*tliis, Jype, 
jrpc:_mgr_Bpv_tKBisleeper_v1_0„ingrJ) ( } 



® 
® 



(b| 



® 
® 



slBepBr_1_Q_ABS(iiuEd_r* type} : 
DCEObi(uuid.r)(OiL 

BCEInterfaceMgr(sleeper_v1 _D_s_ifspBC, (DCEOhj&)*this, tvpe, 
[rpc_mgi_epv.tH&sleeper vl mgr)){} 

// Pure virtual member furtcficns confssponding tc remote procedures 
virtual vcid5l«ep( 

/* [in) *f idl longim time 

} = 0; 



class sleeper 1 O^Mgr '. public sleeper_1_{l_AQS { 
public: 
// CIbss constructors pass couslmctor aiguments to base clashes 
sleeper_1 _Q_Mgr(uoid t* otij} : 
UCEOtiHobl). 
sleeper 1 0. ABSidbj Juuid_t*|(0}H } 



sleeper. 1_0_Mgr( \: 
DCEQbHlubid.r)m 
5teBper_l_0. ABSIuuiO'HD)) { 1 

virtual vaid Sleep(//This rs what the developer must impfemenc 
/* [in] */ idLlong int lime 



tb} 

(y) t^orrespends lo (v) 
Q} Corresponds to (T) 

Fig* 5. Fili^ fpqSN seiTer-side declarafiatis generated by idl++.Ca) 
All Exampie of an abstract ser\^er manager dec laraiioa. (h) An 

example of a concrete server manager declaration. 
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raid fnaJiH ) 
I 

fry { //Kandleexc«pfJonsfrDnii;oifstru£tDf or DC£ calls 

®xi^P«J^O.Wgf * sleeper = uewsJeeper.T.O.Mgr; 7 Drfiamic UUID 
&CEPtfif«sii * eKilTbd = new OCEflliresdiDCCServef- Serve rClean up, 01; 

// tii#Sefvef->Setfiflinel ' i' ,/m^laeper'l. 
(2) // Reftsler Sleeper object with server object 
tfee$efirer->RegiSterObtecti5leepeTh 

// Accept all oitier defaults and activate the seiver 
(5) // Defaults are: Use all protocols, den i use COS, no security 
tboSeTver->UMeni J: 

■1 

// Catch any OCE related errors and print out on message if any occur 
catch iOCEErr&excH 

Iraceab) << "Caiigfit OCE DCEExceptfon^ n' <:< tconst char*}e)(ee; 
1 

// Oestruclors aie nailed ai this point and take care of DC£ claa^iup 
) 

// Developer simply rntplentente one methad to provide itie implementation 

void sleeper_v1 _Q_Mgr : : SleefHIong int time) { 
y/€al| the (reentranCit libc sleep funi^tioft 
s!eep|time}; 

} _.^_ ^ 

m 



tnstance of a Client 
Proxy Cencrele Class 



\V) Instance of Coitcrete Server Ctass 
(2) Register Interface with the Otiject 
(t) Setup for Listen 



Pig, 6, (a) The server program that haitdlos reqiH?sts fcir the Sleep 
Interfate. (\y) Tint* implf^mfntation i>f the SEesp ftiiiction. 



iMtntiirt, clw^ aigv} 



ttf 



f/ Handle eitceptiens frem constructof or DCE calls 



// CfHiStniirtor takes a network address and protocol sei|uence 

siftifflr_1_05f eepC lietrt((iinsigned chsT'laigvIl 1^ 

(unsigned! charTip*!; 

//The Sleep method invokes the remote proctduie on the server 
sieepClienLSIeep^fClL 



catch (DCElrf& execM 
printirOCEException: %s\ n", IconsT cfiar*)execf; 



h 



exitlDl: 



Fig. 7. A clieiit main progmm that iif!Vok#silie Sfecp fiinctton on 
lilt' serv-er. 

OCEfnterfaceMgr is all abstract base clasfi used by the sender 
side of the appUtation to encapsiiJaie object and tj^e infor- 
nuition as well as the entr^' poitit vector called by the RPC 
subsystem when an incomuig RPC is received (see Fig. 5a). 
The maiii^er interface is registered with the DCE run-tiitie 
setup and optionally ^-^ith the naming service. DCEInterfaceMgr 
can retrieve the TUID of a particular iinpleinentatioii ol>ject 
Instatice, the enti3' poinf vech;>r. and I he |)oinfer to the secu- 
rity' reference monitor described by tJie DCERefMon class. 

OCElnterface is an abstract base class used by the client side 
of the application. This class controls tamding and security 
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f^f Sets up security prefefences, which have to be compatible 
with tJia server's security praferences 

\l) Obtains the binding handle to the server 

(3) Cf-»- oh j eel instances defined in the IDL Interface 

C*} C4+ entry point vectors yenerated by idl++ 



(s) RPC nin-tlme server endpoint and server ^ub 

Ci) Checks sBCurrty preferences before allowir^g 
^ the request access to the selected Dbject 

(T) Locates ob|eots 

(V) Set up by user 
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[jolicios and can retrieve object references. Thp if!l-H+-gener- 
ated client prox>' class iiUierits from the DCElnterface class 
(see Fig. 4). 

The HP ( )ODt 'E nUliLy ckia.se.s add convenience Lo the IIP 
OODCE development environment. These classes encapsn- 
late DCR 1yi)es and pruvide direct DCE functionalily. Kor 
example, DCEUuid deals with the DCK C larii^uage rei>resejUa- 
tion of the uuid.t type-^ ajid its possjt)le conversions to other 
tyjjes, while DCEBinding encapsulates DOE binding handle 
types. 

Other utility classes include; 

• Security services: DCERefMon for setting security prefereiices 
and DCERegislry for accessmg the DCE registr>^ database 

■ Nammg services to model and access objects in the 
direcioty namespace 

• Thread senices to encapsulate the use of pthread mutexes,'^'^ 
condition variableSn and lliread policies 

• Enor handling and tracing senices to support an exception 
mechanism and log information. 

The sec urity. naniing, mid thread senices are described in 
the articles on pages. 41, 28, and 6 respecl ively. 

Additional Classes 

AddifioHal cUisses can l)e derived fronj I he iibstract nuuiager 
class to allow for multiple implementations for a given LICE 
interface. Each class nnist be registererl with the global 
serv er (0 C ES e rv e r ) via the L h e S e rv e r o 1 1, j e c t f re in em be r t h at 
theServer is an inst^mce of the DCEServer class). Tliis allows 
tile entry pomt \ ector rode to locate the object manager 
instatice. verify security preferences, and allow^ access to 
the manager niethotls (see Fig. 8), If the manager object is 
not immediately located in the IIP OODCE inteniiU map 
managed by theServer object, the entr>^ point vector code c^m 
call a user-defined method to activate the manager object 
according to user-define fl polices. Once activated, ttie man- 
ager object is reregistered with theServer and atapped into 
the object map. An object inanagei' can be deactivated 
(removed from the oliject ttia[>) when requested by the user 
application. 

VVliile HP OODCE adheres to the olyject model pro%dded by 
DCE, two extensions have Ijeen made to enliance oliject 
fimctionality. An ObjRef class contiiins a reference to ;ui 
object and may be used to i>ass remote object identities 

' uifid_T 15 a C structum cantaimng all the charactetastjcs tar a UUiD. 
•* Mutenfis, Qi mutual excliision locks, aie used tn protsrt critical regions of cod^ in DCE ttireada. 



_, Fig. 9, HP t K )i>(:E (iariievvork and 

utility (jla.ss lihr^irj' f ornpancnts 

between remote objects. When an ObjRef is used to establish 
the binding to an object, the referenced object may need to 
be act ivaie<l by bringing its pensistent data into memorj^ 
from a file, HP OODC E prtjvides an activation structure that 
allows this behavior to be implemented easily by the sen-er. 

The application developer can add framework oi' ntihty 
classes and provide additional mi|"jlementatLons as well as 
charige some IIP OODCE default behavior. Additionally, the 
deve loiter continues to have access to the C langaage-l>£iseci 
DCE APb Direct use of this APIis i^ovemed only by the cor- 
rect mapping of exceptions and the corresponding niies for 
C++ with regard to the C language. 

HP OODCE Exception Model 

One goal of the HI^ OODCE system w^ts to create a consis- 
tent eiTor model. C++ excei^tion band ling was the natural 
choice as the liasis for tJiis model since this inechariisiri is 
already W'cU integrated into the language. C++ provides 
benefits such as object desiniction and reduced sfxirce code 
si/e and is similar in prmciple to the cmient DCE exception 
handling mechanism. 

Despite their siniikuitv^ the C^+ and DCE exception mectia' 
nisms do not integiate well. Exceptions raised l)y one imple- 
mentation cannot be caught by the other, and more impor- 
tant, those generated by the DCE implementation can cause 
memoi^'' leaks if they are allowed to pr oj)agat e through C++ 
code. This latter iirobJem is a result of the u.se of the setjmp 
and iDngjmp fiinctions in the DCE exception implementation, 
wliich do not allow iim-time C++ to call fiestruct<irs for 
temporaiy and exphcitiy declared objects before exiting a 
patticuku' scope. 




OCEOSEKceptiofi 




Fig, 10. Exception dass liierarchy. 
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Fig. 11. Exception hRndllng in 
iiPOODCE. 



To solve the problems raided by the use of two different ex- 
ception mechaiusms. HP OODCE maps DCE exceptions into 
G++ exceptions. Tlie HP OODCE classes are iirranged into a 
C-f+ class liierarchy (see Pig. 10). OCEExceptton is the base 
cIj^s for the hierarchy and provides pure \1rtiiaJ operators 
to convert exceptions to stattts codes or ASCII strings. The 
hierarchy contains subclasses derived from the base class 
for each of the DCE subcomiioiients (T^PC* security, direc- 
tory services, configuration, CIVIA (common multitlu-eaded 
architeclurc) threads, and so onj so Uiat each mdividual 
DCE exception can be caught by type. 

HP OODCE takes particular care to prevent DCE exceptions 
from being propagated directly Into C++ code. At the bound- 
aries between DCE C^ and HP OODCE C++ c<Kle, DCE ex- 
ceptions and error status codes are mapped into HP OODCE 
exceptions and propagated into C-^-f- code. One area I bat 
needed particiUaj- attention was in passing exceptions be- 
tween (he sen^er and cbent. We wanted to use the RPC^ nm- 
tinie implemetiUition of the ser%-ers comnuinicaiion fauh 
transmission, but to do so rpquiieci a "tratislaiion" layer to 
isolate RFC exceptions from HP OODCE C++ code. This 
translation layer is implemented within the idl++-generat.ed 
clieiU i>roxy implementation and seiver entry poiJit vector 
classes (see Fig, it). C-h-h exceptions raisetl iti iht* IIP 
OODCE server are caught in the server entry point vector 
and mai>ped to a DCE status code. This status code is then 
returned to the server stub, which translates the corle imo a 
DCE exception and raist^s h to the attention of the lun-lime 
RFC, The rmi-tiine RPC takes care rjf mapt>ing the exception 
to one of the cunently implemented RPC fatilt codes and 



then transmits tite fault to Uie client. Basically the re\"erse 
happens on the client side, except that here, the chent im- 
plementation class will catch rhe DCE exception niised from 
the client stub aiid throw the HP OODCE exception back to 
tiie client. 
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Glossary 



Although the tarfniriQlogy associated with object-oriented prosramming and d-n- 
has became reasartably siandardized, some objeci-orienied lerms may be slightly 
drfferem depending on the implementatmn Therefore, bfief definitions of some of 
the lerm 1110 logy used irutiss paper are gjven below For more information on these 
terms see the refeteoces in the accompanymg article, 

Abstract Class. Abstract classes fspresent the interlace to more than one imple- 
mentation of a common, usoally complicated concept Because an abstract class is 
a base class to more than one derived class, it must coniasn at least one pure 
virtuat furctioH Objecisf of thrs type can only be created Thnjogh derivation in 
which the pure virtual function implementation is filled in by the derived clas&es 

The following is an example, of an, abstract base class: 

class pt^lygon { 
public: 

// constTUEtor, destructor and other membEr functions 

//cQuld go h&re . 

virtu3l void ratate [rnt 1} = 0://a pufe virtual function 

// other functions go here.. 
}. 

Driver tIassBS. such as square, triangle, and trapezoid, can be derived fmm poly- 
gon, and the rotate function can be filled in and defined in any of these derived 
classes 

Base Class. To reuse the member functiorrs and member data structures of an 

existing class, C-hf provides a technique called class derivation in which a new 
class can denve the functions and data representation from an old class. The old 
ctass is referred to as a base class since it is a foundation (or base) tor other 
classes, and the new class is called a derived class. Equivalent terminolagy refers 
to the base class as the superclass and the derived class as the subclass. 

Catch Block* One (or morel catch statements follow a try block and provide ex- 
cBp; ion-handling cade to be executed when one or more exceptions are thrown. 
Caught exceptions Dan be rethrown via another throw statement within the catch 
black 

Class. A class is a user-defined type that specifies the type and structure of the 
mformaiion needed to create an object (or instance) of the class. 

Concrete Data Class. Concrete data classes are the representation of nevy 
uSB'-delmed ilaiB lypeEi. These user-dehned data types supplement the C+t 
built-in data types such as integers and characters to provfde new atomic building 
blocks for a C++ program Atl the operahons (i.e., member functions) essentiaf for 
the support of a userdefmed data type are provided in the concrele class defmi- 
tjon. For example, types such as complex, date, and character strings could all be 
concrete data types which (by definition) could he used as building blocks to 
create objects in the users application. 

The following code shows portions of a concrete class called date, which ts re- 
sponsible for constructing the basjc data structure for the object date. 

typed ef boolean \nv, 
?deflne TRUE 1 
#def[ne FALSE 



class date [ 

public: 

date lint month, int day, int year}, //Constructor 
-dsteili .//Destructor 

boolean set date! int montb. lot day, int year}; 
//Additional rnembar tunctions could gn hera: . . 

privata 
int year; 
int numeric a Ldaie. 

// AddttionaJ data members, couid go here.. 
I: 

Constructors, A constrocior creates an objea performing initi ah nation m both 
stack-based and free- storage allocated objects, Constructors can de Dverlnaded, 
t)ot They cannot be virtual or static. C++ constructors cannot sped fv a return type, 
not even void 

Darived Class. A class that is derived from one [or more) base classes. 

Destructors. A destructor effectively turns an object back into raw memory A 
destmetor takes no arguments, and no return type can be specified (not even voidl. 
However, destructors can be virtual. 

Ejfceptioo Handling. Exception bandlrng in Ch provides language suppon for 
synchronous eveni handling The C+f exception handling mechanism is supported 
by ttiB throw statement, try blocks, and catch blocks 

Member Functions, Member functions are associated with a specific object of a 
class. That is, they operate on the data members of an object Member functions 
are always declared within a class declaration Member functions are sometimes 
referred to as methods. 

Object Objects are created from a particular class definition and many objects 
can be associated vvjtb a particular class. The objects associated with a class are 
sometimes called instances of the class Each object is an independent oliject 
with Its own data and state. However an object has the same data structure [but 
each object has its own copy of the data) and shares the same member functions 
as all other objects of die same class and exhMs similar behavior. For oKample, 
all the objects of a class that draws circles will draw circles when requested to do 
so, but because of differences in the data in each objects data structures, the 
circles may be drawn in dftferent si?es. colors, and locatrons depending on tha 
state of the data members for that particular object. 

Throw Statement A throw statement is part of the C-h- exception handling mech- 
anism. A throw statement transfers control from the point of die program anomaiy 
to an exception handler The exception handler catches [he exception A thraw 
statement lakes place from within a try block, or from a function in the try block. 

Trv Block. A try block defines a section of code in which an exception may be 
thrown. A try block is always followed by one or more catch statements. 
Exceptions may also be thrown by functions called within the try block ^ 

Virtual Functions. A virtual function enables the programmer to declare member 
funciion^ in a base class that can be redefined by each derived class. Virtual 
functions provide dynamic (i,e,. ajn-time) binding dependmg on the type of object 
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HP Encma/9000: Middleware for 
Constructing Transaction Processing 
Applications 

A transaction processing monitor for distribyted transaction processing 
applications maintains the ACID (atomicity, consistency, isolation, and 
durability) properties of the transactions and provides recovery facilities 
for aborting transactions and recovering from system or network failures. 

by Paiikaj Gupta 



Tjiattsaction processing sij^ems are widely iLsed hy enter- 
]jrLses to support niissioii-critical applications, such as air- 
line reseiTation systems and baiikijig applications. These 
applicatititis need to store antl update data relial>ly, provide 
concmTent access to the data by hundreds or thousands of 
users, and maintain the relhiijiJity or die data in the presence 
of faUures. 

Tlie HP EnciniV9hC)() trajisaction processing monitor ^ pro- 
vides the middlevvai'e for imming transiiclion ixrocessing ap- 
IjUcations. It maintmns Atll) (aloniicity, consistency, isola- 
tion, and durability) properties for transactions (see the 
glussarj' on page 65). h ensures that applications ttuil run 
cone urrently will maintain data consistency. Encina/9000 
also prcjvides rocovei^ facihties for aboning t r'an suctions 
anti recovering trom tailures such as niachiiie <jr network 
cra^ihes. 

DCE and Distribution 

Encina/fiOtKl provides die ability to wril:e distributed applica- 
tions. EncinaAlOOO applications can i>e written as clieiti/sen'er 
applications with the client and server' jjossibly nuinirtg on 
different machines. Encina/flOOO servers ritn contttumicate 
and cooiM^rate vvitli each otiier in tiptlating data on sf'veral 
different niachijies. 

Distributed appllt^atitjus provide sev eral advantages. Tlie 
data maintained iiy an erni^qjrise may itself be distributed 
because of historif^aj and geographical coasi derations. 
FiutJiennore. distrit>nted ai^piications are able to exploit 
piuallelisni by running concnrrently on several niaciiines. 

nistributed computing offers the advantage of improved 
I)erfc^rman<^e. avjnUiljility, and access to distributed data. 
Perthrntjo ice is inij>rnved by spreading the computing 
anKHig various niac^hnies. For example, the appiic*ation s 
user interface can be i-un on a PC' while the nser code coidd 
be split to niti on several tivachines. Tiie use uf nniltiprocess- 
ing machines To fjrovide paiallellsni tbr nnilti{)k^ usei^ c^m 
improve ttie throughput of the system. Avaifabiiity tan be 
increased by a distiilmted system in which replication is 
used io kf^ep several copies of the data. Access tn distrit}- 
uted thita or to data thai is jnaijitained in several datiiJjases 
is also f^icilitated by distributed comtJUttng, 



Data may be distributed because the database becomes too 
large or tlie CPV on the database ntaeliine becomes a bottle- 
neck. Data can also be distributed to increase availabiUty 
and improve the response lime i)y keeinng the data close to 
the users accessing it. Finally, data can l)e distribuied to 
keep sepaiate administiative domains, such as different 
divisions in a corporation that want to keep their data local. 

Encina/POOO uses the Open Software Fotmdation's DCE ^ 
(Distributed Compuring Environment) as the underlying 
mechanism for jnovlding distribution. Il uses the DCE RPC 
mechanism to provide chentyserv ct r(3mnnmication. Encina/ 
9000 is tdso very closely tied to DIE naming and security 
services {see the articles on pages 28 and 41 for more about 
these senices). F^or example, an Enchiii/9000 server can be 
protectCfl fi'orn unauthorized use by detlning access control 
lists (ACLs). ACLs cornain an encoding of the authorization 
policy for different users and are enforced l.jy DCE at rim 
time. ACLs are described on page 49. Encina/9000 also 
makes use of tlie threading package prov1(ietJ by DC >1 

To achieve optimuni [nice and peifonmmce, cai^efnl consid- 
eration needs to be givi*n to how the data ajid the aptjhca- 
tion are partitioned. Jluoughpnl iuu\ resptnise Jimesiire 
often Uie key criteria by which users judge tlie^ performance 
of a system. EnciiuiytHlOO provi<:les the flcxibiUty of being 
able to specify the distribuMon toiJoiogy of the apphcatioti. 
In addition, users can sjii^cily data rephcadon if it will liel|j 
to ensure higher availability of mission-critical data, 

TWo-Tlered versus Three-Tiered Architectures 

In th(^ tjast, trLUisaction pru(*essing applicatioiLs were imple- 
mented using a two-tiered architecture (^see Fig. Ij* In this 
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paiaciigin an application is written as a client, whic-h accesses 
a database server The client inTplenionts Lhe gjaphical user 
interface (GLl) and the application logic. The database 
server handles access to the data stored in a database- 

Tlie tid\ antage of tliis approach ib sinipiirity. The disadvan- 
lago is tliat it is not scalable beyond a ceitain point, it is also 
less flexible and harder to modify to meet new business 
needs. 

Encina/9000 allows the development of applications using a 
three-tiered arclutectvu-e like llie one showu in Kig, 2. In this 
paradigm, an appliLaiioii is partitioned into a client that im- 
plement's ttie grapliical user interface to tlie user, an appbca- 
tion server tJiat hiiplements the business logic of the appii- 
cation, and a database seiner that implements the database 
access. 

The Encina/9000 three-tiered architecture provides the fol- 
lowing ad\ antages over traditional two-tiered architectures: 

• Decoupling the GUI from the business logic 

• Scalability of the architecture to support a ver^' large nimi- 
ber of users and a higli transaction tJu'ouglit^nt 

• Accessibility to nndtiplo database sen ers from ^m apphca- 
tion sen-er 

• Freedom from beuig lieti into any particiUar tlatabase 
vendor 

• Tight integration with the distributed computing facilities 
offered by DC'B: 

• Choice of transact! (J iial aiiplications that support any com- 
bination of Rf'C, CPI-C (CfHi^mon Progtannning Interface 

f oj* ( : om mu ni<' at i ons ) , an d ( tm m i et 1 1 1 1 essage con un u n i c 'alio n 

• Ability to retain data on a inainl'rante or other legacy com- 
puter and reengineer by adding HP-UX'^' application servers, 
providing lower cost and higher price/performance relative 
to some niamframe systems. 

Three- tie red tm^hitecfuresare more complicated in ^encr^il 
but provide greater tiexibilily of application design and dc- 
veiofnnent. Among the reasons why users are willing to give 
up the simplicity of the two-tiered aichitecture is the faster 
response times and the more effective user interfaces pro- 
vided by the three-tiered arclutectme. The abilit>^ to provide 
a front-end workstation that supports graphical user inter- 
faces gives an applicatir/rt a more effective nsci' interiace. 
For apphcatioris that retjuire access to data distributed across 
large geographic regions, a three-tiered arcbitectvu-e offers 
more flexibility to tune the cmnnumications to contpen,sate 
for WAN delays aJid itn])rn%e avjii lability. This results in a 
faster response time l>ecause the user is accessing local data 
most of the time. Propagatitai of the data to other macbines 
can be queued snxd perfonned offline. Therefore, geographi- 
cally distributed data can be maintained witjioia having to 
perfonn cxijensive distributed two-phase commit protocols 



online. Two-phase commits that happen over wide area net- 
works are expensive and care must he taken wlien deslginng 
distributed applications to minimize the anion nt of two- 
phase conunits over the network. Queued conutmnications 
also improve availability See page t>5 for a delltiition of 
conmnu 

Compoiients of Eiiciiia/0000 

Fig. 3 shows the arclutectme for the implementation of 
Endna/^OOO tiiaL runs on the Hl^-UX'^' operating system. 

Each of the components shown in Fig- 3 is packaged inde- 
pendently. A machine that runs Enctna/900() clients only can 
be configured withoul lhe Rncina/9tK)U server software. 
Machines that rtm Encirtii/ilOOO servers must be conHgured 
with l>odt rhe Encina/9000 client an<! server components. 

Encina/JKllit) applications that cmi be ccmfigured to run on 
top of the Enciiia/9000 server comp^jncnt inclufJe; 

• Peer-to-peer communication, which pra\i.des transactional 
access to dat^ stored on mainframes and workstatioris run- 
ning the fiP-I iX operating system 

• Structured file system, w^hich is a recortl-oiiented file sys- 
tem base on the X/Open -' ISMl (index sequential access 
method) standard 

• Recoverable queueinj^ sen ice, which i provides apt) licatioe^s 
witli the al)ility to enqueue and detjueue data 

• Monitor, whit^h is an infnist met mv for ap[>hcation develop- 
im^nt, nni-tinuvsupport, ajid aditiinistration. 

The Dt'E components used by Encina/900(l include; fil^', the 
dirc?ctoiy service, the security service, and tlmeads, 

Encina/9000 Toolkit 

The Encina/J^flOO client component is also called ttie Encina/ 
9000 toolkit executive and the Encina/9000 seiver component 
is also called the Encina^'DOOO toolkit server core. Together 
these components are called the Encina/9000 toolkit* 

F^g. 4 shows I be components that make up and support the 
Enrina/9(K10 toolkit. 

Base Development Eitvironment. The lowest layer of the 
Encina^''9(KK) toolkit isthe base develoijnient environment 
It provides developei^ of oUier Encina/9000 components 
with a miifonn set of features inde|)entlent of the underlying 
ot>erating system. Tlie base development environment lji)raiy 
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provides a common platform ind^pendeni tlireading inter- 
fece and aii al^straciion for lDw4e\ei ftinctions so that the 
upper layers that iise the base development environment 
can be independent of differences in the operating sj^ent or 
the hardift'are platform on which EncinaAXHK) runs. 

The base de\-eIopment environment provides support for 
multiple threads of execution by using DCE threads. Also, it 
provides thread-safe routine for the following ftmetioiialjiy: 

• Memory management 

• FUe I/O 

• Process management 

• Signal handling 

• Timers and alarms 

• Native language support. 

The base development environment is intended primarily for 
the development of other Encina/9(KX) components. 

Transactmn Manager. The transaction manager provides the 
ability- to den\aj x^ate transactions, which means that it is 
able to specify the begimiing, the conuuit, and the abort of a 
transaction. Internally it supports a (iisiributed tw^o-phase 
commit management protocol, including the ability to per- 
form coordinator migration. 

The transaction manager supports nested transactions capa- 
bility/^ which allows nested transactions to be defmed witiiin 
a top-level trLuisaction. Nested transactions have isolation 
ai:td durability propeities similai' to regulaj' transactions, but 
the ahon uf a nested transaction does not cause the top-level 
transaction to abort. This allows a fmer gianuiarity of failure 
isolation in wliidi die main transaction can handle tlie fail- 
lu'e of certain cnjiiiionetUs implemented with a nested trans- 
action, Nested trattsactiom) are defmed in the glossary on 
page 65. 

The applieatitju nuist he carefully designed since failures 
such as crashed server nodes, which cause a nested trans- 
action \Q fail, could in scmte cases jilso faiise Hie top level 
trtmsaction to fail, l^he Encinii/9f)iM) stru( turetl file system 
provides su|)]H)i1 for nested li ansarlions ftjr data stored in 
structiucd filos. However, datal)ase vendors like ( >racle do 
not currently support nested trtutsactions in their prodiK^ts. 
making it impossible to exploit the advantages of Encina/ 
9(K)trs nested tiajisactior> capabilities for data storetl by 
these rtlational databases. 
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The E^ncina-WOO transaction manager provides an applica- 
tion program with the atiilitv" to issue callbacks on events 
related to the transaction s commit protocol Tliis enables 
the programmer to write routines that are in\^oked before 
the transaction prepares or aJjorts or after the coordinator 
decides to abort or commit the transaction. 

The transac^on manager allows trai^acdons to be heuristi- 
ealiy committed by a system administrator This should only 
Im used in rare cases in vvhicii the transaction coordinator is 
unavailable and tiie administrator does not wani to block 
access to locked data and lias to trade off data av^ailabilitj'^ to 
a^'oid possible data inconsistency^. 

Thread-to-TlD. Since Encina/9000 makes use of DCE threads, 
the work done on behalf of a user trat^action can be com- 
posed of several different threads. The tliread-tn-TID senice 
associates a transaction with a tluead and Jiiaintains the 
mapping bet\^"een a tiiread and a transaction identifier (TTD ). 
Tliis seivice is used by other Encina/9000 components and is 
rarely used by programmers directly. 

Transactional RPC. The Encma/9000 transactional RFC ser- 
vice enlitmces the DCE RPC mechanism to provide transac- 
tional semantics for remote procedme calls. Unlike remote 
procedure calls, transactional RPCs have once-only seman- 
tics, ir a transaction perfonniiig un RPC commits, then the 
R!*C is guaianteed lo have executed once and once only. If 
the transaction perfonning an RPC ai)orts then the RPC is 
guai'anteed not to have executeti (if the HPC was executed 
its effects are undone by the transaction abort). 

A transaction cati make i r;uisacTionaJ RPC calls to multiple 
seivers, anti a sener can in tiu'n make a transactional RPC 
call to aitother server 

The tiartsactional RPC service extends the DCE RPC model 
'Hie interface dennitiou for the service executetl on belialf 
of a tratisaction is deflt^ed in a TIDL ClVansactional Interface 
Defmitlfm Umguage) nU\ which is shnihu* (o a DCR 11 H* 
Qle.^' Tills file nuist he tMcprocessed wilh a TIDL compiler 
(similar to an IDL compiler). The TIDL preprocessor gener- 
ates cUent stubs, seiver stubs, a header file, and an IDL file, 
Tlie DCE IDL preprocessor Ls run on the IEjL file to generate 
additional stubs and header files. The chent and the seiver 
executables are generated by compiling and linking the vari- 
ous stub sotU'ces and libraries. This process is illustrated in 
Fig. 5. 

Transactional Rl^C also supports nontransactional RPCs (a 
nontransactional RPC call can lie made l)y c^Uling the trans- 
acticjnal RPC senice), The TIDL file for the senric:e interface 
must specify that tlie senice is n on transactional. 

Log. This component of EnciJta/9000 provides logging capa- 
bilities. It provides write-aliead logging (see glossaty) for 
storing log records that cnrrespond lo updates to recoverable 
^ataand log records thai correspond to transaction t out- 
comes. Tlie log records are used by the transaction nmnagcr 
to undo the eiTects of fransactions itiat have abmtt^d and to 
ensure that the committed transactions are durable. 

• StB the aniclfl on paigt 55 for mtjre sbour IDL filas. 



Fig. 4* A d^^tiiiled view of tlit^ rnniptiruMii.s tViat mnkr iip md support. 
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(l^J Pre process uanssciion throtiffh the T(01 ctrmpirer 
{2J Hun the IDL file cre^teif in (1) through the IDL compiler 
[ZJ Create the client pragram. 
(V) Create the server prog ram. 



Fig. 5. TtLe steps ijivolvc'd in luming 
ft I J annaction into ciit?ri) iinrj sender 
exeeutabteii* 



Vor earlier versiuiis of Encina/9000, the log semce wiis 
iinpleitiented to pro\icle a log server that could be used by 
iTiaiiy different (Clients to store log records. The latest ver- 
sion of Encina/9000 siipporls tlH' log setvicT as a lil>raj:>' 
wMch is linked into the chent code. 

The log -service supports arciiiviiig of log data for crash arid 
meiha rec:oveiy It also supports mirroring of data. 

Lock. This component provides two-phase locking (see glos- 
sai>' ) facilities to ensure the isolation luid consistency proi>- 
eities of traiisactioiis. Applications can retjiiesT locks on 
resources before accessing tlieni, and the lot k manager 
ensures tliat the lock request on liehalf of a transaction will 
ni>l be granted If aii other transaction holds a conllicting lock 
on that resource. Locks are reknised automatically when the 
transaction completes, and the application may j^so request 
Ciirly relejise of locks when it is safe to do so. The lock ser- 
vice also supports locking for nested transactions. 

Tlie locking service implements logical locking in which the 
ptogramrner dermes lot*k names aitd associates the lock 
names with physic<il restiurces. When a proj^rantmer wants 
to lock a physical resource, tlte logical lock nante associated 
with tiiat resource is specilied in tlte call to the lockhig 
service. 

In addition to suppoiiing the conventional read/write locks. 
EIncii^a/90€() also suppoits mtention locks and iitsrant tltira- 
tion locks. Intention locks are ttsed to decliire an iittent to 
substH^uetilly lock a resource. Tlte use of intention locks rait 
reduce the potential for deadlock among concurrent trans- 
actions. Instant duration locks are Jocks that are granted but 



not held and can be used to iniplentent codnplex locking 
algorithms. 

The lock service also provides the ability to detenmine if a 
transaction is deadlocked or nob 

Volume. Tliis component maintains the data storage in l.enTis 
of logical data volumes. It provides the ability to tnanage 
very large files and view mullipk^ j^hysical disks ;is a virttial 
file. It also supports the alnlity to rniirora data volume 
tratisptirent ly to Itte client. The v(^lumt^ roniponeiit some- 
times sacrifices speed for uicreased reUiibilitv' and may be 
inappropriate for certain applications. Tins coin|:>oneiit is 
cmrently not used by the log component. 

TM-XA. The EncinaTDOOO T^l-XA comptment implements the 
X/Open XA interface. Tht^ XA mterface is a biiiirectionid 
itvt erface between a transaction manager aiid a resotirce 
manager such as a dataliase. Tlie XA interface provides B 
standard w^ay for Iraiisaction Jitanagers to connec^t to tlata- 
bases. 

The use of TM-X.\ with I he Enciiia/f)0OO monitor is rerom- 
niended. In litis case the serv-er registers !?ach resotine man- 
ager with a call providing the name t>f the rosoui-ce manager 
and an associated switch structure.^ which gi\'es the Enchia/ 
90()tJ TM-XA component infonnation about the resource 
manager. In addition, the set^^er must also be decku^ed as a 
ref*overable seiver. TM-XA allows Encina/9tXJfl to hook up 
with standard database products such as Oracle, Informix, 
and so on. 
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Glossary 

The foltowing sm Ijrief defirvFtioos of sflim of the tranaactioiHelaieiJ iermimilc^ 
used in tfie accomisan . 

Trans^ctJOfis apt) ACID 

A ira-Msacii^jT^ rS tns yg^cai q^Qu^m of a user function perfoirnKJ as a unit so that 
\i mainiains its ACID (atoTncity, consistency, isolation, ami dwabilJtyl pmp^ies, 
Tran^ctiofis alEow usars to &x6cute their pragi'aTns and modify shamd resources 
fike databases tn the presence of sjmuitarteous access and upcJstes t>¥ multiple 
users and in the pnsgnce ^ymm% kinds of failures 

Aiomlcity of a transaction means that either all the actions specified within the 
transaction will be performed or none of tfrem will be perfdrmed This ensures that 
a transaction is not partially appfled. which is desirable since a partial applfcation 
of the user transaction could leave the database in an rnconsistent state, Consis- 
tency means that the database consistency is preserved in the presence of concur- 
rsntry among multiple users isotation means That white the transaction (S execi^'t- 
ing, its effects will no! be visible to other concurrently running transactions. Du ra- 
ta ility means that once a transaction has been successfullv completed the effects 
of that transaction are made pennanent and survive fai lyres, 

Commtt, Abort, and Preparo 

A successful completion of a trarisactiDn is called a i:omm/f of the transactmn. 
BefarE a transaction commits, it can be aborted either hy the user or by the trans- 
action pracessmg system. 

A user orgsni^Bsa set of actions in s transaction with the intern that all of these 
actions should happen or none of these actions should happen. An example of 
such a transaction is a transfer of money between a person's savings account and 
checking account This transaction consists of ttie actions of changing the ss\fings 
account balance and the checking account bate nee. If the transaction is successful 
then both these account balonces should be changed, me debited by amount X. 
and the other credited by amount X. Any other outcome would be in error. When 
the user submits this transaction and all operations in the transaction are success- 
fully earned out. the transaction is sajd to have committed, 

It may nnt always be possible to commit a transaction. For example, the machine 
that maintains the checking account balance may be down, or the user may have 
supplied an incnrreci personal identification number [PIW[ or decided to cancel the 
request after submitting it. II the transaction cannot be performed, then it is said 
to have been aborted or simpiy to have aborted. If a transaction is aborted 
(aborts}, then none of the actions of the transaction are performed (or if they had 
been performed they are undone). 

Transaction processing systems use mechanisms like two-phase tDcking to ensure 
the isolation properties, and fVi/(7-p/73semmm/f protocols to ensure that all the 
parttcipants within a transaction can be atomicatly committed or abonedJ 



A vm^^Amsa conrnut protDCol is lYpicatty os€d to corrMnii a transacbon [n which 
multiple participants are performing actitms requastHi by iM transactitjn One of 
these participants is called the cDor^it^tor In the f?rsl t^t^e of tfie two-f^tase 
commit protocol, the coordinator seridsa pr^re message to all the particioants. 
asking tf?em to prepare tfte transaction and send a message back indiiattng 
whether or not they can pref^re the transadJon. tf all the partMrrpants respond 
that tfigy can preiisre the trans^ion, the coctrdinator writes a record in its log 
tndieatfog that tt>e trarisactiofi is cofmmftted m^ mitructi; all tht panictpants to 
commit the transaction (this is the second phase of the pnatocoll. If any participant 
respmvds back to the coordinator that it is unatie to prepare the transaction, the 
cooniinator notes jn its log tnar the traosactjon is aborted aM instructs ell partici* 
IBnts to abort tha transaction 

When 3 panicipant receives a commit message from itie coordinator in the second 
phase, ft must ensure that all the actions of the transaction are durably stored on 
disk. When a participant recerves an abort message fn^m the coordinator in the 
second phase, it must ensure thai all the actions of the transacilon are undone. 
Tfierefora, in the firsi phase of the two-phase commit pfotocol, the participant 
must ensure that data is stored reliably in logs that enable it subsequently to undo 
the effects of a transaction or make permanent the effects of a transaction, 

Nested Transaction 

In the nested transaction mode], a transaction iaiso called a top-tevel transaction! 
can be decomposed into a tree-like hierarchy^ Far example, a debit^:redit transac- 
tion can be decomposed into two subtransactions, one for debit and one for credit 
The debit or credit subtrans actions could be hjrther decomposed into smaller 
SUbtransadions, A subtransaction maintains the durability and consistency proper- 
ties of Its parents. The difference is that a suhtransaction can be aborted and 
reexecuted without aborting its parenl In the debit-credit example, tfie debit 
suhtransaction can he aborted and reexecuted without having to abon the entire 
transaction. In this case the top-leveJ transaction verifies that each suhtransaction 
can be committed at the time of transaction commit. 

Two-Phase Lacking 

Two-phase locking means that a transaction will have two phases. In the first 
phase the transaction can only acquire and not release locks, and in the second 
phase it can only release and not atiquire locks. 

Write-Ahead Lagging 

For data recovery, transaction processing systems use a log to fog data that JS 
being modified, In write-ahead loggmg, data is copaed to the log before it is over- 
written This ensures that if the transaction is aborted, the data can be restorad to 
its onginai state; 
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TM-XA allows m\ Encma/9(I(K) application tu ituikc calls to 
one or more resource managers tJiat support the XA inter- 
fare. The Encina/fiflOO appli('ati(.jii starts a transact ion ^ 
accesses a resomce manager iisirtg its luitivr- SQL interface, 
and then conunits the transactirm. The TM-XA software 
coordinates the commit of the transaction among the vaii- 
ous resotircc managers aiid otiier Encina/ 900(J r:oniponenls 
[like the stnicuired fiJe system or the recoveralile (lueuhig 
systeni) vvhiiHi niight be accessed by the user tninsactiotu 

Recovery, Tliis romi:>onent drives the recovery protocols to 
reco%^er from failures. It provides recoverable memory mem- 
agement. Recxjvcrj'' idso provides the ahilily \o perform: 
Aliorl r(*covery, Tliis ensures tli at after a transact ioit is 
abfirhMl, it is rolled l>ack at all pai1icit>afing sites. 
Clash recovery. Tliis in-ovidi^s a recovety after a system 
failure by rolling back all the transactians that had not been 



committcci and rolling foi'W'ard all the conmiitteci tians- 
actions. 

* Media recovery. TTiis is used to provide recovery when data 
written to the disk is destroyed. 

The recovery component produces and uses the records 
wTitten by the log seivice and ensures the consistency of 
tiansactional data, hi the case of a transacticjn failin^e, the 
rec^overy comji^onent undoes the effects of a transaction. 
During recover^" from a system failmT, this comi^onent will 
examine the records m the log, approj^riately commit or 
abort transactions for wiiich it fmds records m the log, and 
bring the data to a consistent state. 

For media failures, the systerti adtumistrator must provide 
archives that are tised by the recovery component to restore 
the data to the state it was in w hen the archive was ereatetl 
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There may be a loss of data in the case of media reco\^er>'. 
I:i;ncina/9000 kiiso provides the ability to perfomi online back- 
ups to create the media archi%'es necessary' for recovery. 



be executed as a subtraiisaction within the parent trans- 
act ion. The subThreed construct allows a created tliread to be 
executed as a sepai^ate thi'ead within a nested transaction. 



Tran-C 

Enciiia/DUOO provides extensions to the C progranuning lan- 
guage to mal(c it easy to invoke the functionality provided 
by the Encina/9000 toolkit. Tran-C* consists of library func- 
tions and macros tJiai provide a simple programming para- 
digm so that the user does not have Ui access the* toolkit 
module iiiteilaces directly. Tlie user can invoke high-level 
Tran-C constructs rather than the lower-level toolkit calis. 
The u.se of Ti^an-C* versus toolkit calls is analogous to using a 
Inglvievel iangtiage v^ersus assembly language. Using die 
toolkit primUlves directly is much more flexible, but the 
flexibility comes at the price of far greater complexity. 
In general. Tran-C is recommended for application 
progranmihig. 

The most important constructs provided by Tian-C are the 
transaction. onCommiL and onAbort clauses. These constructs 
provide a mechmiism for the progranmier to start a trans- 
action and declare cotle to execute when the transaction 
commits or aborts. This is illustrated in P^ig. G. The applica- 
tion programmer is freed from the lask of initiahzing all rhe 
tmderlyijig loolkit components and mammlly managing 
transaction identifiers. traiisacMonal locks, and other trans- 
actional metadata. All the code bracketed by the transaction 
clause is executed on behalf of the same transaction. When 
a transaction bounded by the tiansaction c^onstruct aboits 
(or c(jnunits}. control in the program automatically transfers 
lo the associated onAbort (or onCommtt) clause. 

TVan-C also supports nested transactions and multiple tiireads 
of control. The cone jr rent and cofor constructs ran be used to 
create nmltii>le conciurent direads within a transaction. The 
concurrent ct>nstmct is used to eiuil)le an application to com 
currently execute a predetermined Jiumber of threads, while 
the cafor construct enables the application to concurrently 
execute a variable number r>f threads. Both constnicts pro- 
vide the ability to create multiple threatls which can be run 
eidier as subtiimsactions or iis concmient threads widun tJie 
transaction. The subTran construct allows a created diread to 

iransi^cfioff -< — Siarts a TraitsBcHi^n 
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Toolkit Example 

Fig. 7 shows an exajuple of the interactions between the 
components of the Encma/0000 toolkit. In this example a 
client makes a call to update data stored by a database and 
then conmiits the transaction. The following steps are assi> 
ciated with the ciiTled numbers in Fig. 7. 

L The client starts a trajxsaction by maJdng a call to the 
transaction manager. 

2. The client performs a transactional RFC by making a call 
to die transactional RFC component, 

3. The transactional RFC com|)onent makes a eaU to the 
ti'snsaction manager to obtain transactional data for the 
transaction. 

■1. The transactional RFC component calls DCE RFC to 

transmit the user data and transactional data to the server. 

5. DCE RFC (on the sen^er) makes a call to the I ransatllonal 

RFC. 

(j. The tTdnsaclional RFC component passes die trajisactional 

infonnation lo the iransaclion numager. 

T. The transaction tnajtager uses the TM-XA interface to call 

die resource majiager. 

S, Tlie transactional RFC component calls the user fmiction 

that nTakes SQL calls to the resource manager The resource 
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manager peifomis the appropmte locking and updating of 
its data 

9* The user function on the sen-er returns to that trans- 
actional RPC componi^nl whit^h titen returns to the client \1a 
DCE 

10. The client calls the transaction nian^ej- to connnit the 
transaction. 

11. The transaction manager uses a iTscHphase com nut pro- 
tocol to conmiit the transaction. It coniacis a]l the tmns- 
action manager parricipains that have participated in the 
transaction. Each transaction ntanager uses the recover^' 
and log comtionents to log the prepare and conmni deci- 
sions during I'arious phases of the commit protocol for the 
transaction. 
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Peer-to-Peer Conmtunications 

Encina/J^(H)0 peer-to-peer comniunicadonSf or PPC, provides 
transactional access to data stored on mainframes, and it 
perforins a distributed twophase commit of data stored on 
mainframes and HP 90Q0 sen^ei^. This allows mainframe 
applications to parricipate in an Encina^9[)0(J tr^msactional 
application, imd con\'ersclyH an Encina/'9()i)0 application is 
able to participate in a mtunframe transacLional api>lication. 
Ettcirui/0()(K) PPC^ uses a two phase connnit sync protocol 
{sync level 2) to contmit a ti^isaction that accesses data on 
a mainframe and ati HP 9000 sender. 

PVC services aie implemented as a PPC executive and a 
rt*C gateway iiroduct. These products can be purchiised 
sejuuately. The PPC executive is a library that nuis in a DCE 
rell, aufl the PPC gateway is a sen-er that acts as a gateway 
betw^een DCE and SNA comiuunications protocol. Tliis gate- 
way allows Encina/90()0 applications to conmiunicate witli 
LV (12 ap|)lic!atif JUS, ' 

A topical PPC configuration involves an Encin 9/900(3 I^PC 
application ninnitig in a DCE cell and ctHntnunicating with a 
PPC gateway sener ninniiig in itie sanie DCE cell. The PPV 
gateway server comaiunicales with the inalnfi*ajue using mi 
SNA romnninic aiions package. PPC provides the aliilhy to 
write F^iK iniVS'UOO ap|>licaliotis thai act as either die coordi- 
nator or tlir sulKXtlinalt" in a trmisat'licjn iK4ween iu\ Encina/ 
nooo system and a inaiufratne Iiost. Encina/9000 apphcatiou 
programmers use the CPI-C* API for codii^g the PPC compo- 
nent, Tlic PI^C gateway tnuislates the CPI-C conversations 
from TVPflP In LVii± This is illusl rated in Fig. 8. 

Structiired File System 

Thu striKiured file systett^ is a record-oriented file system 
based on the X/(>i)en ISAM standard. It provides ati riherna- 
five to (jther conuuercial resouif(^ jimnagers and tht' cibility 
to sujiiiori nested transactions that at^cess data in the stnic- 
fLu*ed file system. If also provides full trat\sactional integrity. 

The records in the structured file system contain different 
fields tltat can be intlesed by priniar>' keys iumI secondary 
keys. Tlic strn(1ur«H[ file system's field and record tyiiesare 
similar to tiiose ust^d by ihe re<*overable queuing service 
(d(\sc^ribed below), allowing applications to have easy access 

* lU B if applications are maintraine aE^plicarions that ara vvrftten to fuh an tdp of \BM'^ LU 6.2 



to both systems. In addition* the stntcttn^l file siystem sup- 
ports a COBOL mterface with the stnicntred file system's 
external file handler. 

Files in the structure* I file system are orgajiized in one of the 
following three ways: eurty-seciuenced, relative, and B-tree 
clustered (see Pig, y), Records in ait entry-sequenced file are 
stored in the order in which tliey are wTitten into tlie file. 
New recortis ai'e always appended to die end of the file. A 
relative file is an an'ay of fixed-length slots. Records ciui be 
insenecl in the tirst fi'ee slot found from rhe beginning of the 
file, at the end of the file, or in a specified slot in tiie file. A 
B-tree clustered file is a tree-structured file in w-hich records 
with adjacent index luuneSiU'e clustereil togetlier. 
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The structured file system is simple and fast, but Limited in 
tlexibility when comjiaied to relational databases. RelationaJ 
databases provide powerFul and coniplex access semantics 
with operations such as select, join, aggregate, and so on. 
T\\e smicl tired nie system provides low-level access to rec- 
ords whose fontials are user-defined aiKl t't>atrolled. 

Heroverable Queueing Service 

Encina/9OD0 probities a recoverable queueing senlee which 
is layered on top of the basic toolkit and scner care compo- 
nents. This service provides applif^lions witli the abilitj^ to 
transactionally queue and dequeue data Application devel- 
ojjers can write applications thai IransactionaJly update data 
in a resource rtianager^ like a dataljase and queue or dequeue 
data with I he guariuUee tlsa! eidier both operations will 
succeed or botli oi)erations will aborh 

An example of a transactionally recoverable queue would be 
a banking application that sends a letter to a customer if the 
custtuner's balance goes below zero. The action to generate 
die letter can be queued and processed later at the t^nd of 
the day. Tlie recoverable queue ensures that this action will 
always be performed even in the event of system failmes- 

One advantage of the t|ueueing model is that applications 
can offload some work to be done at a later time. This de- 
feiTed mode of com]>uting is h\ contrast with the RFC style 
of comtnmiication in which nn applit ation invokes a service 
to do tlie processing as soon as it can. 

A queue is a lineai^ data structure. Elements in the data 
stmcture are queued in a particular configurable order and 
the dequeue occurs on a FIFO (first in, first out) basis. An 
element of a reco\^erable queueing senice queue is stmc- 
1 VI re f I hi a rec ord-ori ei 1 1 ed tV j r i u a t . K n c i n a/900 supp oris 
queues tiui! may contain elements ordinereni data types. An 
element key is a secitience of one or more fields of an ele- 
ment type that are used to retrieve an element. 

Encma/9000 provides tl\e ability to define one or more re- 
coverable qtieiieing senice sen-ers hi an Encina/9000 cell. 
Each sen er cai^ intemally support multiple queue sets. A 
queue set is a collection of queues witliin a recoverable 
queuemg senice sener. Applications can queue or dequeue 
to or from a particular queue set. Queues within a queue set 
can be tissigned priority classes relative to each olhen Also, 
senice levels delhie how to distribute the dequeues so that 
the queues witti lower priority are not starv^ed. 

The recoverable queueing senice siq^ports a vv^eak FIFO 
lockuig behavior. For example, w^hen two transactions con- 
cuiTcntly dequeue fi-om a queue, each obtains a lock on the 
first element that it can lock on the queue. It is possible for 
the transaction thai obtained a lock on the second element 
in the queue to conunit ]>efore the transact ien that cjbuiined 
a lock on the first element in tlie queue, i^nodier consequence 
of the weak FIFO locking pohcy may be tiiat a ti'aiisaction 
that eonsecutixely queues nndtiple elements may not be 
able to place all these elements hi that queue in an munter- 
nipted seqtience. 

The recoverable Queueing senice uses the DCE secmity 
mechanisms to secme access to the queue, Administi-atively, 



ACLs (access control lists) can be set up to authorize users 
or groups to tie able to perform qtieue operations like read 
from queue, queue to the queue, dequeue from the queue, 
delete a queue, and so on. 

A recoverable queueing senice queue can be scamted ushtg 
element keys, cin-soi"^ (for sequential access), or element 
identifiers. 

Finally, the recoverable queuemg service provides the ability 
to register callbacks with the senice 's sen'er on callback 
quantities sucli as the number ot elements, size jji bytes, tmd 
work accumulation. For example, with this feature it is pos- 
sible to write applications that can ask the recoverable 
queueing senice sen'ei' to infonu them wl>eji ten elements 
have been queued. 

Monitor 

The Entina^OOOO ti-aiisacdon piTJcessing monitor i)rr>v!des 
an mfrastntcture for apphcation development, niretime sup- 
port, and admimstration. It supports the development of a 
three-tiered aicliitectiu'e m which multiple clients can access 
data stored in multiple resource managers. 

Like DCE, die Encina/9000 monitor also has the concept of a 
cell. For the EncinaA>000 monitor the cell is called im Eur la a 
celL The Enclna ceU is a subset of the DCE cell, and nmltiple 
Encina cells can be defined within a DCE cell. (DCE cells 
are described in the article on page J An Ertcina ceil may 
consist of multiple nodes, A no^le is either a public node or a 
secme node. A secure node is a iied*^ on which the Encina/ 
9000 senders can be securely nm, f\ibijc nofies are nodes 
where only clients are run. Senders ai'e not coidigured to nm 
on public nodes. An example of an Encina cell is shown in 
F'ig. 10. Like DCE, an Encina cell has a cell aciministrator 
who is responsible for performing administrative tasks. 
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Tlie encina cell contains the follov^lng sender processes: 
Cell Manager. There is one cell manager process in an 
Encina ceU. Tlie cell manager maintains the data needed fo 
configure and administer the Encina cell. This data is stored 
m a data repositorv" managed by the structured file system. 
The data describes how the application scr% eis are config- 
ured to run on the secure nodes and include the authoriza- 
tion information for those servers. The ceM mattager also 
monitors the state of the node managers and keeps statistics 
on the use of the seners by the clienls. 
Node IVIanager Tliere is one ntxie manager process in each 
secure nt:Kle in an Encina cell. The node manager monitors 
the apphcation servers that are nmning in that node. If an 
application sener fails, the failure is detected by the node 
manager which then restarts the appUcation ser\ er. 
Appltcation Server, The sen-er part of a user application is m\ 
application sender. IVp^C'^ly' application ser\ ers accept caiLs 
from an Encina cells clients and then process tlie user re- 
quests by accessing one or more resource ntanagers. Apph- 
cation ser^'ers may be recoverable or ephemeral. A reco\^er- 
able application seiver is one that uses the underlying 
Encma/9000 facilities to provide the ACID (aromicit>^. con- 
sistency, isolation, mid dmability ) transactional properties. 
When a recoverable server fails, it performs recovery on 
restart which guarantees the consistency of the data. An 
ephemeral sender does not provide the ACID propeiiies to 
the data it accesses. An applicaticn server consists of a 
schetluting daemon process (called mond) aiul one or more 
processes (called PAs) that accej»! client requests, PAs aie 
raultitlneaded processes, Tiie mord coorduiates the clients' 
requests for servers and assigns a PA to a requesting client. 
In this respect the role of the mond is sinulai" to that of the 
RPC daemon rpcd in DCE. Tire mond also monitors the FAs 
and antomaticaliy restarts a PA in the event that tJie PA dies. 
An example of an application nmning in an EncniiVOtJOt) cell 
is shown in Fig. 1 1 , 

in the Encina/9000 monitor emdronment, a chent can make 
a server request using explicit binding or trimsparettt bind- 
ing. With transpment binding the client simply makes a call 
to the server and the monitor einmfmment is responsible for 
routing the client request to an appropriate server. With ex- 
pMctt binduig, a client explicitly binds to a particular server. 
The Encmii/900D inoiiitor provides a call to reqtiest a list of 
all servers exporting a particular inteifacet a call to get a 
handle to a mond for one of those servers, mid a call to gel a 
handle to a PA that is under the control of a particular mond. 
Wher^ using explicit bindingt a client can spei ify that the 
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client block if the PA is biis>' or that it get back a status if the 
PA is bus^. hi addition, the client can request that the PA be 
r^raerv^ed for that client by specifying a long-ierm reservation 
to the ser^'er 

In general it is easier to code the chent to use tratisparent 
binding. This also has tiie advantage that the monitor code 
can perform load balancing of client requests among the 
a^'ailable PAs. The monitor sofli%"are uses a probabilistic 
algorithm lo route client requests to tlie av^ailable PAs m a 
TBtio predefined by a system adnunistrator. With transparent 
binding tJie momtor sofr«'are wiH use an existiirg binding if 
one exists, or it will create a binding to an appropriate 
server if no such binding exists. If all the available serv^eis 
are busj; the chent waits at the sen"er for a free PA. 

Althougli if is more comphcated to write chent s thai tise 
explicit binding, it does pro\ide the user with the ability to 
select tlie PA on which tire call is executed. There are cer- 
tain situations m which explicit binding used in corymtction 
with long-term resert ation of PAs is acfvantageous. For ex- 
ample, consider a chent process servicing a large number of 
users, hi this case it would be advcifilageous lr:»r that process 
to rescn e a PA and theJi direct rtie various user requests to 
that PA, [laving a til reel connection to a PA reduces the time 
needed to connect to a PA on subsequent calls. Long-temi 
reserv ation makes the PA unavailable to other cheats, and it 
must he used with care, AdministTativcty, a timeout interval 
can be specified so that if there aie no chent calls to the PA 
witliin that interval, the long-term reservation is canceled. 

When an applicaiion seiver is mitiaiized. it can specify one 
of the title e scliedulhig policies: exclusive, eoncuiient shat ed, 
and shaied, Shmed scheduluig is provided primarily for 
compatibihty with previous releases, aiul its use is not 
recommended. The ciefaull policy is exclasive scherluling. 
With this scheduhng only one client UVC can be executing 
witliin a given PA at any time, and the PA is scheduled exclu- 
sively lor the etitire duration of the client transaction. This 
has tlie advantage Itial the [>ingrammer does not have to be 
C(jncerr>ett ahoiit issues related u> rlireading. Tlus is requiied 
when tiie PA is accessing a database tliat is not thread safe 
(which is currently the case for most RDBMSs). 

W^ith concurrent shared scheduling, many clients can be 
executuig within a PA at the same time, and the multi- 
threaded PA assigits a different tlu^ead for each client re- 
quest. If tlie PA accesses global or static variables, they must 
be protected by DCE synchionization facilities such as 
mutexes,'^' Concurrent shared scheduling should only he 
used when linking with tluead-safc hbraries, tJoiieunent 
shared scheduling provides the best perfonnance with the 
lowx*st use of resotnces* 

The monitor allows the creation and access of monitor- 
shared memory (IIP 9000 \iitual memory) which can be 
shared among the PAs within an application serv'^en This 
allows a quick mitl easy way for the PAs to share (tan-sac- 
tional tlata, Monil (H-shared menioty is much cheaper th?u\. 
say, usmg an external RUBMS, but care should be exert ised 
when using the monitor-shared memory because it is ti\e 
user's rej^pfinsibiliiy to perfonn the approijriate locking 
when aceeSsSing the shared memt)iy. Since locks must hv 

' lytuteKSs, or mutual SJiclusiQn locks, me used to pratectcnticEl regions of code in DCE threads. 
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used, it also has the potential of introducing deadloclcs. 
TYaiisactionaJ dnieouts cmi be declared for aborting such 
transactionfi. 

The monitor allows the use of the recoverable queuemg ser- 
vice for queueing work items which are eventually prorressed 
by a monitor application server Using the queued request 
facility, entries of the approjiriate ty^7e tire queued to the 
recoverable queueuig service. A queued request facihty 
daemon will then dequeue the request and forward the 
request to the appropriate PA, 

Tlie Encma/iJUtJi) nioniior aiso provides a timer mechanism 
to aHow ser\^ers to schedule a rail to be issued at a later 
lime, Tliis fimctionality is provided transartionally so that 
the call macie within the scope of a tiansartion is sciiefhiled 
If the iransaclioji commits. The call does not occur ii'the 
tratisaclion aborts. 

The Encina^9000 monitor provides suppon for application 
dcvclopei-s whcj wish to integrate their Encina/9000 client 
v^ith fornis-hased user inteitace tools. Encina/9000 is inte- 
grated with JAM, a font^s-based tool from JYACC Inc. 

In summary, the Encina/OOOO monitor provides the following 
benefits: 

• Simplified prcigranmiing for writing clients and servera 

• Automatic detection of fail tires and resttul-s of monitor 
daemons and PAs 

• Automatic load l>aiancing between clients cind servers 

■ CoUeclion of statistics by the monitor for server use 

• Simplified central place of adnmiistration for distributed 
clients and ser\ ers 

• Support ft>r highly concurrent access to relatioiial data- 
bases. 

Standards Supported by Eneina/90fJ0 

Encina/900() supports the following standards: 

• X/Open: 

om 

OTX 

O TxRPC API 
o CPl-(^ 
o ISAM 

• SAA: 

o CPIC 
O CPI/HR 

• OSF DCE. 

EnciJUV^DOO interoperates with the following products: 

• Oracle 

• fiiformix 

• Ingres 

• Sybase 

• Open CICS 

■ IBM main frame CICS 

• IBM mainframe IMS/DC, 

Tile EnciJia/9Q00 toolkit lias been used to support other 
transaction processing products and provide the base func- 
tionaJity to snppon other products like Ojren CICS and 
STDL each numing on top of Encuia/9000 on the HP4JX 
operating system. 



Value-Addecl Features 

HP Enciiia/9000 provides value-added features in the areas 
of system administraticjn ^uul high availability. 

System Adniliilstratiuii 

An Enf1ua/90tK) system administrator nms! configure the 
Encina cell atid tiefine the admuiistrafive interfaces for the 
various servers in t.lie system. 

An Encina cell must be closely tied to a logical administra* 
five imit of vt^ork, and the data accessed !o do diis work 
should be m the same cell. It is possible for api)lications to 
interoperale across Encina cells using ex])licit bindhigs* 
TiierefoHN ( be exact boimdaries of mi Encina cell must be 
defmed by carefidly analyzmg the apphcations nuuiing in 
the system with carefid consideration being given to secu- 
rity, number of users and machines, location of data, artd the 
applications ibal access the data. 

A system admuiistrator must create d"Le log space used by 

Encma/9(]00 and then bring up the following Encina/9000 

components: 

Structured file system 

Cell nuinager 

Node majiiigf^r 

■ Servers sticb as the recoverable queueing service and the 
PPC gateway if dtey are needed 

The required apphcation servers. 

Encma/9000 provides athninistration tools for \he folloHing 
components: log, st.nict tired file system , monitor, recover- 
able queueing senice. PPC, and Ihe rest of the toolkit These 
tools pro\ide the apprfjj)riate low- level cominaiK{s for ad- 
minLstering these components. Encina/9(K)0 aiscj provides a 
perl-based* tool called encsetup, w^hich pro\ides higher-level 
system administration facilities. The IIP value-added systent 
administration facilities arp described laler in tliis section. 
Finally. Encinii/OtKJO also provides libraries t^>r fieve loping 
system adttunist ration product s^ whicli are ver:y^ useful for 
customers developing these kinds of proflucts. 

EncinaA^OOO system admmist ration is very closely tied to 
DCE sy.siem adnu'nist ration. Tlie DC'E cell must be config- 
ured before rite Encina cell t*an be configured. Encinii/9000 
also makes use of the DCE directoiy service. The dpfault 
Encina root celt tUrectoo' is defmed as /.:/encina (this default 
can be changed if needed). Encina/9000 conn>onents regis- 
ter their name mider tliis cUrectoiy'. Within this director>' 
there are directory^ entries for tJie recoverable queueing ser- 
vice, the structureti fde syslem, the Encinti/fUJOO monitor, 
transactional RFC, iind peer-to-peer com nturu«*ation (PPC). 
For example, each recoverable toolkit server registers an 
enXry in the /;/encina/trpc directory (trpc - transactional RPC*). 
and each recoverable monitor server registeinij an entr>- in 
the /j/encina/tpm/trpc directory (tpm = Encina/^OOO monitor). 

The use of the directory allows the Encina/fJOOO system 
athninistrator to re-Strict access to various resomces. The 

■ Per3 (Practical Eirtigctii^n Report Langusgej (S a UNIXptogramming language shat iS desfgned 
to haridle system adtnmisirator funaians 
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system adnimistrator can use DCE tools like 3cl_edrt to grant 
a user a group, or an organization permission to access a 
particii^ resource. Encina^'QOOO uses the DCE authentica- 
tion and authorization mechaiusnis to maintain security. An 
Enrina/900(l sener can specify the !e\'el of authorization a 
user of the sender must ha\"e to access that server A client 
wishing to at^cess a secure server must be authenticated vaih 
DCE an<i when tlie client caMs the server, the sen-er uses the 
DCE security mechanisms to verify whether it should allow 
access to the user DCE access control and security are dis- 
cussed in the articles of pages 49 and 41 respectively. 

HP pro%ides a DCAM layer for Eneina/9000. DC AM stands 
for distributed computing application management. DCAJM 
is an architecture and melihotiolog>^ for pro%iding miiform 
^stem ntanagement for products that enable distributed 
computing .such as DCE, Encina^OOO, and C^ICS. An advan- 
tage of DCAM is tiiai It provides a consist en! look and feel 
for all of these products to tlie user and aids in the overall 
ease of use of tiiese products. It provides a grapltical user 
interface as well as a DCAM shell. DCAM prt:>\1des a set of 
action verbs that can be modified by options and operate on 
objects. 

Fig. 12 shows the relationship between the DCAM CLl 
(command-lit^e interface) layer, the DCAM shell and SAM 
(system administration manager). 

SAM is a menU'driven interface used to manage an Enciua/' 
9O00 system. Tlie DCAM shell is a commautl-iine interface 
which ctm be used to tjype in adniinistrative commands. 
SAM mid the DCMl shell are layered on top of the DCAM 
CLl scnijiLs whi<.*h conven tlie DC^AM commands to native 
End na/9(J()0 ad ni i n i strati on e t ) nmiands. 

The conunon look tmd feel proxided by DCAM enal)les a 
system administrator to manage the differeiU distributed 
systems and applicralions based oti DCE with a ccmsistent 
at id user-fi'iendiy interfac*\ DCAM does tills by providing 
consistent use of vocabulary' i" reiiresent actions. Tlie con- 
sistent use of syntax and semantics is imprirt^ai^t betrause of 
the different subsiretetns thai 1>C AM is buih ut^on. The con- 
sistency ptt)\idt^d by DCAM improves user efficiency and 
low^ers error rates. 

DCAM provides a natural way for system adntinistrators to 
ex[>ress tlie actions that they wan!* For example, to create a 
structured file system sen^er, a system administrator would 
type the conunand: create sfs server This command is converted 
by DCAM to the underling Encin;t/l)(JO(J low-level eonmiands 
needed to create t he server. 
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The SAM interface of DCAM is more usefiil for people w ho 
are familiar wxxh SAM or are getting acquainiefl with Encina/ 
9(100. nie DCAM shell is generally used for efficiency by 
experienced Encina/9000 system administrators. In addition, 
the DCMI shelJ is also used for writing and customizing 
sv'steiii administration scripts. 

DC AVI is objeci-oriented. Objects represent items that can 
be encapsulat€^ and acted upon, Encina^OO^M) objects can be 
an Encina cell, a sen^^er, or a irattsacdon. ObjecLs have attri- 
butes. For example* a struct ured file sj^tem ser^-er haa an 
associated attribute that describes the log volume associated 
with the sener Actions are verbs that act upon the objects. 
For example, the actions create, stan, modify, and stop can 
be used to act upon an object. Actions tiave object indepen- 
dent semantics in that they l\ave sintilar semantics regardless 
of the type of object they are working on. For example, tlie 
\^rb create can be used to create ari Ervrina cell, a structured 
file system ser\^er an application sener, and so on. Actions 
have options. An action can be specified with the defaidt 
options, or the administrator can st:>ecify task-specific op- 
tions Hiih the action- 

A task defines a pairing of an action with mi object, A tiisk 
consists of one action, one object, zero or more options, and 
one or more attributes. For c^xample, start ceH -Name name, 
which tells DCAM to stait up the named celJ along with 
other optional parameters, is a task that can be specified 
with thf DCMT shell. If the parameters are not specified, the 
DC Ml shell will prompt for the pariuneTers, In S.AM, the 
paiameters are displayed as fields in the SAJ^l panel and can 
be entered, Lf the retiuired j)arameters are not entered, an 
error is dist^layedn 

Another useful feature of DCAM is the help facility, which 
can be used by the system administrator to interactively 
obtain help on a topic. This is also useful for someone who 
Ls learning Encina/9000 administration since il lists the vari- 
ous tdtematives and options to a command and pro%ides an 
easy way for administrators to get a feel for the vailous 
conunands and options. 

To many users the real value of DC!AM is tlie added capabili- 
ties it has that go beyond what nath'e Encina/9(H)() arhnini.s- 
tradon supports. This intrudes bigli-level server configura- 
tion tasks which are much easier, complete support for 
traiisparenr remott^ configuratitin from an>"where in the DCE 
cell, autorestart of t<:>olkil sen'ers like the structured file 
systeni and the recoverable quetieing sendee, and sutipun 
for Ser\1ceGuardA.'X*s failover* feature. 

High'AvailabLlity Features 

Many cust timers have a strict requirement for data to be 
available at all times. Data n'plication with Encjna/9000 can 
be provided by the use of data mirroring with mirrored 
disks. In addiiinn. to provide data availability in I be case of 
machine t;iilnres. Encmti/BODO t an t>e iniegratcd with the 
Swire ho ver/L'X and the Ser\iceGuartl^UX products (de- 
scribed below). Tliese products iillow node lailuies to be 
bandied, and they provide a set of scripts tliat facilitate the 
admmistration of a highly available system, 

' hilCNGi refers to ihs p(ocB5S that occurs when a standby fiods takss over from a faHed nods. 
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Ill a distributed system there can be many causes of failures, 
and faiiures of disks, networks, and niafhines can all impact 
availabiUiy, Since the system is compf)sed of several nodes 
connected with network lir^ks, lliere are more points of fail- 
ure that could impact availahility. Network failures are nor 
described here, but users who need highly av^iilable Encina; 
90()r) ai>ijlications should ti:y to avoid single points of nei- 
work fiiihuc 

Many techniques exist for dealijig with disk failures, Tlie 
preferred method of dealing with disk failures is to use 
HP-UX mirruicd disks with a logical volume manager. Other 
choices arc* to use RAID' or to use Encin^iyyOOO minored 
disks. Tile advantage of die HP-l 'X minored disk technique 
is that it is a general-pm7)ose solution with applicability ro 
all kinds of data hke the stiuctured file system and DBMSs. 
If the database can handle the logical \'olume manager con- 
figured for no consistenc:y then it should be used for data- 
base data. Mirror wiitc consistency or mirror consistency 
should be used for Encina/9000 data or for database data 
that can handle consistency mirromig. RAID can be used as 
arelati\"e]y inexpensive solution to handle disk failures, but 
it has mai^y single points of failure in the disk I/O jjath and is 
not good for tiie short random wilte updates dial are typi- 
cally fomid in transaction systems, Encina/9000 mirroring 
has the disadvantage that il is not integrated in the Hf*-UX 
operating system and can therefore only be used for Encina/ 
9000 data and not for, say. DC'E or DBMS- Its advantage is 
that it car^ auloniatically Iiandle more failure conditions than 
HP-l.rX miri'oring. EncijitiAlOOO miiToring is .slower than 
HP-UX mirroring, l)ut it has a ftister recoveiy time. 

There are two primary solutions for node failures: Switch- 
over/lJX and Senit cGuaid/UX. In Switchover/L-X, a primary' 
node and a staiidhy node are configured with nuiltibosted 
disks. The primajy node rqis in the nonnal case. The stitndby 
notle is also connected to the disks ^md uses a heaitbeat 
protocol to detect failure of the piimmy node. V\^ie!r the 
stai\dby node detects that the primmy node has failed, it 
assumes the primary nodes identity i>y booting off the pii- 
mary node's disks and using the primary node's IP address. 
The standby node then uses the primaiy i^ode's disks lu re- 
boot aiid ro restart the system processes and applications, 
Tliis billows a fast restart aflet^ tlie piimaiy node has 
crashed, resultmg m a small downtime, Tlie primar>' and 
staj\dby nodes should be from the same hardwrn-e family. 

With Switchover/! "X the Encina/^KJOO processes ai e restiuted 
when the stai^dby ncKle reboots. L'siiig Encina/fJOOO's trims- 
parent binding, clienm are automatically reconnected to die 
servers. However in this case client transactions will keep 
aboil ing until tiie failover is complete. 

In ServiceGuajd/UX, applications and data are encapsulated 
as packages that can be nm on vanous nodes of a cluster. 
ServiceGuard/t'X aUows the user to define the packages, 
and each package has a prioritized list of nodes it can run 
on. Ser\iceGuat <I/I ^X ensiues that a package only nms on 
one node at a tinie. A package is defmed by a slmtup/shut- 
down script and can represent any application, 'Ilie nodes 
nuuiing packages monitor each other's status and restart 
packages when they detetl I he failure of another node. 

A package can be an Encma/9000 application sen er nimiing 
under a single Endna/^HJOD node manager Tiie package can 



also include assorted toolkit servers like the structured Jdle 
systenii a recoverable queue ing service, or an Encina/9000 
monit(»r. Djittcuially, a package can have one or more IP ad- 
dresses. If specLBetl^ a package's IP address is asso<:'iated 
with the network interface on the machine cuiTently execiU- 
ing the package. With ServiceGuarfl/I'X a user em) configure 
a simple faito\ er scheme. Tlie user can also define a single 
package that can execute on a primaiy^ or a backup node. 
This scheme is general and can be used for the Encina/9000 
log, structured file system, rc^coverable queueing service, 
monitor, ajul DBMS an\I DCE core sen^ei-s. 

Flruina/9000 sen^ers can be integrated v^iih xSer\iceGuard/ 
I'X, In this case the Encina/OOOO server's should be config- 
ured in a SemceGuardiTJX cluster. ;uk1 a package should be 
created for the servers. The package sliould contain run ajid 
halt scripts for the servers, wiiich specify tlie actions to take 
wjien a package is started or tenninated. Tlie acti<:jns in a 
run script inclutle adding the relocatable IP address lo the 
network inf erface, momiting all logical ^•olmnes. aiid calling 
an Encina/9000 script lo start all the Encina/9000 serv^ers. 
The actions in a halt sc ript include cidling an Encina/0000 
script to halt aW I he Encina/9000 sei-vers, munomithig ^ill die 
logical volumes, aiul removing die relocatable IP address. 

Ser\iceGuaid/l^X offers a more fiexihle solution for liigh 
availabihty It <;:an he configured with a dedicatefl standby 
solution similar to Switcliover/LiX, or it can be coidlgm'ed in 
a more cluster-like configuration. It also has a faster recov- 
iny time since failover nodes do not need to reboot. 

Encina/9000 also provides the abihty to perfonn api>Ucation- 
level replication of data. An alternative to application-level 
replication is the repUcation of data provided by databases. 
Database-level replication has the adviuUage of being trans- 
parent 10 the user, imd ir is relatively efilcient. Application- 
level replication, on the other hai\cL Is less dependent on 
specific DBMS jjlatfomis and can be used to provide repUca- 
tion across DBMS iilat forms. In addition, it is more fiexible 
and can be perfonned in a synchionous or asyTichronous 
niamicr. It may be impoilant ( < > periorm asj^chionous repli- 
cation across a WAN to achieve a faster response rime. The 
djsadvaiuage of applicarion-level replication is that tiie ap- 
plication developer must design and implentenl the replica- 
tion scheme. 

/\n example of replication using Encina/9000 is master/slave 
replication of data witii defen'ed updates to the slave. In tliis 
scheme, the [ntister copy of the database is maintained on a 
machine. Tlie application updates the master database and 
stores a copy of the U|Klate in the recoverable queueing 
service. Witii tiiis setup the apphcation can transactional iy 
update the master database and store a copy or the U|)dates 
in the recoverable quenehig service. At a later time the data 
is ti'aiisactionally dequeued from the recoverable queueing 
seivice ^md applied to the slave database on anr>ther ma- 
chine. The strength of tlus approach iy tliat the two lua- 
chiJies hi)kling copies of the data do not have to l:)e nmnmg 
at tiie same time, and the update can lie defen ed to a time 
when die load on the system is low. It also avoids lia\ing to 
do online a tv\'o-phase conunit across the machines. Ilow- 
ev^er. there is the drawback that the replica is j^crt consistent 
with the mast e IV and the updated data would be imav£ii]able 
while the master node is do^^m. 
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Encina/SOOO-Easpd Architeettires 

Some of ihe roimnon Eiicina'9*XMJ'based architectures in- 
clude corporate centralized data architecture* i^gion 
centralized data architecture, and brancli data arelHieeture. 
in each of these architeciurFS we consider a ctir^ioration to 
be an enfiiy dial has a ceniral data processing center located 
at its headquarters. Tlie corptjrations business is geographi- 
cally spread over se\'eral regions, and each regioital center 
has a data pnKes^ing center Elach region also contains mul- 
tiple branch offices, and the branch ofiice has a number of 
users who are executing transactions. In the t>ast. CDiiipa- 
nies employed mainframes at the corijoraie headquarters, 
where all the data was nimniained. This was expensive to 
maintain, and the response tinxe got worse as the data on 
the mainfrajtte increased. 

hi a corporate centralized data architecture, data is still 
iiiatniained al I he mainfratiie host. Connection to the main- 
frame is through gate\\a>' machines that nm tfie Bncina/rJOOO 
PFC executive. Depending on the availability requirements, 
thegaieway macf titles could be implemented with the liigli- 
availabiljty solutions mentioned earlier. One option would 
be not to have any machuies at the branch oflices or the 
region offices but rather to have PCs at these oflices which 
talk directly tci the mainframe. Alternately I he regional cen- 
ters or the branches could have mactujies, iind the regional 
machine could route a request fmm a bratieh to the ci^rtJO- 
tate center. Alt the data is maintained at the corporate cen- 
ter and tliere is no local business tiara at either the regional 
offices or the branch offices. ThLs architecture is shown in 
Fig. 13. 

This arfhitectin^e is useful if it is Iiard to replace the main- 
frame machitK^s mid data. Alternately it may be possible to 
offload some of the data from the mainframe to machines 
nt ruling the HPt JX operating system at the coqiorate data 
center. 

The regional centralized data architecture Is similar to the 
corpoiatc centralizert data arctiilecturc. exrcpt that the data 
is piulitioned across the legioniU data centers. The data 
could also be stored witJi the mainframe at the corporate 
dala center. ChetUs can nm at the tnanch machines or at the 
reglonai ceiileiv Optionally, there could l)e a database at 
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either the corporate center or the regioas thai assists in 
routing a request to the appropriate regional center This 
architecture is shown in F^g. 14. 

In the regional centralized data architecture, Encina/tKMK) 
seners typically run on the regional maciiines. Clients can 
run at the branch or regional offices. CUents employ lookup 
niechanisins to locate the appropriaie server and then make 
calls lo the servers. M\ ElncinMlCXX) PPC can be used fo 
transacDonall}' read or update data stoi^ at the corporate 
ce-nter. 

The regional centralized data architecture hiis the ad\^aniage 
of avoiding CPU bottleneck problems when a large number 
of iransactioi^ have to be proces.sed on a single database. 
Since the databases are spread througlK>ut the regions, they 
all can handle transactional access to the data allowing a 
higher volume of transaction^ titiffic- In addition, if users 
frequently access data at the nearby Regional center net- 
work traffic \\ill be localized- 

In the brancli data arcrlutecture, each branch maintains its 
local branch data. The data c^m also be aggregated and 
maintained at the corporate center, but users prinianly ac- 
cess the data at a branch machine. ()ptionally con^t^rate or 
regional tenters cku\ maintain a cross-reference database to 
assist with routirtg a user retiuesr to the appropriate branch. 
Tliis arcliiieciure is shown in Fig. 15. 

The main ad\'antage of this solution is the fast resjionse time, 
since for most transactions data can he lof^ked up locally 
and exi^ensive t%vo-phase commits over the WAN can be 
minitnixed Tl)e drawback of this scheme is ha\ing to main- 
tain a large number of databases and administering them. 

Conclusion 

The Encinti/'IKKK) jnodiKi jjif)vides an application develop- 
ment emironniem lor develfiping OLTP applications and the 
mn-time stiiJport tor ruttningand adniinistcnng tlu^ at>i)tica- 
lions. Its strengths are the Oexibiiity it provides foi' distril)- 
utefl OLTP aijplit'atioiLs cotnpared lo the tratlitionaJ tlata- 
base products, and its strong integration with tlu^ UP DCE 
product. It jirovidesim infrastructure tor cusiomtTS to write 
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iT-Uahlp aiid sec lire applications for theii' mission-critical daia. 
Additionally. Hio Encina/90()0 piiKlucI pro\if}es acklod value 
in rho meiua olsysteni adniinisiriit ion iind t£iull tuleranc*?. 

Ac kii owl e d gill ent s 

I wfHild Jikf In 1 ha] I k lay Kasi IVir hi.s insightful discussions 
on several lopirs Ent^iiisont^fl iji diis paper. 
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Object-Oriented Perspective on 
Software System Testing in a 
Distributed Environment 



A flexible object-oriented test system was developed to deal with the 
testing challenges imposed by software systems that run in distributed 
client/server environments. 

by Mark C. Campbell, David K. Hinds, Ana V. Kapetanakis^ Da\1d S. Leiin, Stephen J- McFarland^ 
David J. Miller, and J* Scott South worth 



In recent years j^oflrw'are technology has evolved from 
single- machine apph cations to multimachine applications 
(the realm of the client and server). A\su, object-onented 
prograjinning techniques have been gaining ground on pro- 
cedural program mijig languages and practices. liecently, 
te^st engine PI'S l^ve focused on techniques for testing ob- 
jects. However, the design and inipiementatjon of die test 
tools and code have remained largely procedural in nature. 

This pa|)er will describe the object testing fr^miework, which 
is a sotYware testing framework designed to meet the testing 
needs ot new software tectaologies and take advantage of 
object-oriented tec^hniques to nuixiniize flexibility and tool 
reuse. 

System Softw^are Testing 

The hovels ofsoHware testing inchide luiit, intcgraiion, anrl 
sy.stem le.sting, Unil tesiing ijuolves testing iiicti\itiiLal sy.slein 
niodules by themselves, integration testing involves testing 
du" iiidivithial modules working together, and system testhig 
involves lesriiig tlif whole product in its actujil or simuJaled 
of>eratiitg environment. This paper focuses on software 
system testing. 

A software system ie.st is irvttnided to determine whether the 
software product is ready to ship by ol>servTng how the 
product performs over time while aitem]iting In simulate its 
real use. System testing is composed t>r tunclii>u;il, perhjr- 
I nance, and stress tests. It atso coven* ot>^*^^l ^t>nfil, instatta- 
tion. and usaliility ai>|>eets of the produet imd may inchitle 
destructive and eoncunenee testing. The product may su|:>- 
poil many differeni hiirdwjue mtfl software configurations 
which alt require testing. All of these aspects aie combined 
to assess the product's overall reliabihty. Sottwaie system 
testing is usually done when all of tlie individual software 
produft comi>otumtsare ctMnpleled imd LLSst'nibled into the 
OnaJ product . 

In I h e 1 lasl . syst e n 1 1 es ting e n\1 ron 1 1 wj} ts v e n t e red aroi i nd 
1 es t i ng p r'o t c dura ) , i ion ( t i st ri b u t c<t st ) It ^^ at e . '\ h es e en vi rt m- 
lui^nts, which were also procedural and nondistributed, 
wr/re usuaUy developed by the t^^sl wrii^Ton an aci hoc- tiasis 
alon^ with the U'sl Cfule tor the prnrtnrt, Rerenlly, stjflware 
sysh^ni jesting has bcni^nicd rrom tlir^ use ijf highly :mt(> 
nmied test harnesses and ejiviromnents iliai smitilify test 



execution, results gathering, and report generation (see 
Rg. 1). Unfortunately, the test h*miesses created in these 
environments were not easil>^ reusable, and when tiie next 
project reached the test planning stage, the test harness had 
to be rew^orked. 

Tile advent of standardized test environments such as TET 
(Test En\'ironment Toolkit )^ helpeil to reduce this costly 
retooling by providing a standard Af^l f apfjlication program 
interface) and tool base thai test developers can adopt and 
use to wTite stantlardized tests. However, the difficulty is to 
provide a stand^ml test harness that is complete but flexible 
enough to keep pace witli changing software technolog>' and 
remain viable for the long tenn. 

During 1 lie development and testing of the initial release of 
HP ORB Plus, which is an oliject reqtiest broker l>aseci on 
the Oliject. Management Group's C'ORBA specification (see 
page 7t7), we realized that distribuied object teclmokigy 
posed testing proldems that wvtv not adetiuately solved l>y 
any of the test hxmiesses currently available. We needed a 
Oexible test envinmment tliat could hamlle heterogeiieous 

' The Tesr EnvtfJnnif^nt Taolkil (TET) specitir.3JJori began in SeptHJnbef iSBSssa joini proposal 
by tha Open Sattv/are FDundation. UNIX'"' Intarnatianaf. and X/Open''*' 




Create li 

by Test 

DcvGlopsrs 



Uier Inteiface 


■! 


Test Harness 


1 


Tesi Test 

dm Case • • • 
2 3 


CbS9 

H 


1 # • 4 

* V nr 


T 


1 Svsiom Unifttf TcisMSmi 1 



Go»nrtraiid tine or GUI 

CanfiguralJEin Management, 

Test Coiitro!, 

Rep on Generaiiofi. eic. 



Test Scripts. 
Test Cases, etc. 



Fig- 1. A typital aiilu[imlr (i [mhI cnvinHUTiiMii, 



)Copr. 1949-1998 Hewlett-Packard Co. 



U<'< t'mlKT \Mb ni^wt<fli-l*JirkHid -]<HU7isil 75 



tlistiibuted systems communicating over nniltiple transports 
using 11 1 ul I it lir eaded clients and spn^ei's. However, we were 
riot willing to lose the investment we made in the tesL code 
and tools developed for olu- earlier products. 

Instead of abaiuloning the old test environment and replac- 
ing it with m\ entirely new system, we decided to use the 
ohject-oriente^l principles of ericapsnlatiun and imlynior- 
phism to evolve our current environment base to meet our 
needs without throwing out lite old code. The ability' to 
change or replace functional blocks of a system without 
iifi'ecting tlie entii'e environment is njie offlie mum benefits 
of object-oriented design (see ''Object-Oriettied 1-rogram- 
iniT;g" on page 79), Object-oriented j^iinciples allowed us to 
reuse existing tools. 

Distributed System Testing 

In a distiibuterl object system, service providers are distrib- 
uted across a netw^ork of systems and aie called serv^eis. 
Clients, wiio issue requests for those services, are also dis- 
tributed across a Jietwork. A single progiam can l)e b<jlh a 
client (issues requests) and a sen^er (senices requests), 
Clients can issue requests to local m\d remote servers. Dur- 
ing a distributed object system test, clients are responsible 
for reporting any failures or status resulling from the re- 
quests they make. 

The first task peifonned dui ing the system testing of a dis- 
tributed object softw^are [jroducl is lest setup. Clients and 
servei*s must be deployed across the network lo targeted 
systems. Consideration must also be given to the fact that 
seivei^ may have multiple clients sending messages K j them, 
and the fiisitihutifju of clients Lmd serv-era may change <hir- 
ing a system test so that various haixlw^aiT and software 
configurations can he tested. 



The Object Management Group's 
Distributed Object Model 

The Object Management Group lOMGI creates standards for the mterflperability 
and portatitlitv of distrtbuted DbjecL-DrJeniecf applicatfons The OMG onfy pmduces 
specifications, not software, Each participating vendor provides an imp[flmeni3' 
trcn to meet the specificatfon. TTie Common Object Request Broker Architectufs 
(CORBA) specificatson defines a flexible framework upon wliicli distributed object- 
onented applitiations can be built. This architecture represents the Object Request 
Broker {ORB) technology that was adapted by the OMG. An ORB provides the 
mechanisms by whtch distributed objects transparently make requests and receive 
responses, The ORB enables object-oriented applications on different machines to 
communicam and infteroperate. 

The OM(j has defmed an Object Management Architecture object model. In this 
model objects provide services, and clients tssue requests fur those servar^es. The 
ORB facilitates this model by delivering requests to objects and returning any 
output values to the client The services that the ORB provides are transparenr to 
the client 

To request a service, a client needs the object reference for the object that is to 
provide the service. The ORB uses this object reference to identify and locate the 
object The ORB activates the object if it is not already exeeutirtg and directs the 
request to the object 



Wlien test clients ex*?eut.e, they are instructed to mn for a 
specjlieii ajiiouDt ot time. Tliey report failure and status in- 
fomiation back to a ceiitrai location. Upon completion of 
the Bystem testt clients anci servers are stopped, temporary 
files lire renioved, and final summary reports are produced. 

The Tetit System 

To manage all five aclivitiehi cjf distributed system testing, we 
develojjed a test uifrastriKftire tliat met rjiu- cvurenl needs 
and could evolve witli new leclinologies and new needs. We 
followed a modular, ohject-oriented design appn>ach to 
accomplish this. 

We firs! engaged in several brainstonmng sessions to pro- 
duce a list of requirements for a complete disnibuted testing 
framework. Iliis wa^ an attempt to pinpoint all tJie attributes 
and fn!t(^tioivality that a ''perfect" test infrastructiu-c would 
have, aiiil ii was tione in the context of system testing dis- 
tributed objects, Tlie needs of prodtict developers, test de- 
velopers, and testers were crynsidered, as well as the need to 
report metiirs to tiie [project team. The main Uk-us, however, 
was on the two gronps wiu* won hi tise the test framework 
the most: test developeis and testers. Often these are lite 
same people, but the distinction was made to clearly differ- 
entiate the needs of each group. 

Product developers noriTially want quick and simple tests to 
verify that their code beliaves correctly and at llie same time 
have their programs work as I liey would for an entl user. 
They don't w^ant to be distracted by the infrastruciure. Exist- 
ing test APIs tend to be intrusive^ requiring developers to 
have knowledge of the test environment in which their tests 
will i)e RU^- Therefore, wv W' anted oim new" test frame w^ork 
to mhiitni^e intnisiveness. Tliis would allow^ deveiopera to 
focus on t estit^g the jnoper behavior of their code ajid not 
on the test infrastnictore. Ideally, product developers should 
be able to wTite their tests wilh inininKun restrictions, and 
the tests should plug and play in many different testing 
sititations. 

Test developers, w4iose job It is lo develot> ways to test the 
product, have many of the same needs as prociuct develop- 
ers but are more concerned with black- box testing and tiy- 
ing to "break" the product rather than verif>ing correct l>e- 
havior, Jo do this, test developers w^ant to be able to plug 
new tests into the test environment easily and quickly, and 
they w^ant pr(K ess and environment control This w-ould 
aliow' them to use the same tests in different scenarios to 
find more product defects. Test developei'S are tistially the 
ones resjDonsible for supporting the testing uifrastructiue. 
Thus, more than any of the other gioups, test developers 
need a frame w^ork that is extensible, reusable, flexible, and 
contralled, and hopefully has a long lifetime. If a testing in- 
frastructure liecomes oul of dale, test developeis will have 
to repmr or replace it. 

Often test developers are the ones who perform system test- 
ing, but inm\v tunes this role is handetl off to testers. .^dTOugh 
the needs of both giotips clearly overlap, testers need a lesT- 
ing infrastnictme that is eas>' to use fur the installation, con- 
figimation. mid execution of tests. In many of our past proj- 
ects, testing w^as done by teniporaiy pei^onneL Tltis freed 
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test developers to write more tests and assist product devel- 
opers ill ciebugging. UTieii the test infrastructure is eas>' to 
use, the testing role can be handed off to testers earlier in 
the testing process. Additionally, tiie abilit^' to reconfigure 
the test enwonment easily and quickly allows more scenar- 
ios to be tested. This increases the likelihood of finding more 
product defects, which leads to a better quality product 

Finally, test restilts are usually provided to the project team 
in tite fomi of metrics. Gathering metrics in a distributed 
emironmcnt can be ttme^-consumLng. Data can foe located on 
multipie systems on the netw^ork. However ^vhen dealing 
with multiple processes running in parallel on different sys- 
tems, results may not aJways occur in a consistent order. 
This iniphes tlie need for a centi^aiized repositor>^ for testuig 
residis. This would make the generation of metrics much 
easier and fastcrn wlule providing a central location for find- 
ing pr€*blenLs and debugging. 

Design Methodologj^ 

Taking mto consideration the needs of the different groups 
mentioned above, we decided that the foUowing attributes 
were required for om' test infiastnicture. 

• Extensibility, Ensure the evolution of a modular system that 
can be dealt witli on a component-by-component basis. 

• Rensability. Allow object arid code reuse for both tests and 
the test infrastnicture. 

• Flexibitity. Pi'o\1de a plug-and-play environment !l\ai allows 
for fiexibihty in test wilting and conllgmation. 

• Sinniiation, Provide the abihtj^ to simulate customer 
enviroruneTUs. 

• Control Provide centrahzed control of the test processes 
and enviramnerU.. 

• Nonijitrusjve. Hide as much of the testing infrastructure as 
possible from tbe system under (est, 

• Ease of use. Provide ease of use for Installation, setup, con- 
figuration, execution, resulrs gatJiering , and test distribution. 

With these attributes in n\ind, we set about deciding on the 
basic set of classes t liat would be needed. We used a method 
for objeet-orieJUed design calletl Object Mudelmg Technique 
(OMT)^ to develop a diagram showing class relationships 
(see "^Object-Oriented Progranuninj?" on page 79). 

We walked through several scenarios and expanded and 
refined our set of classes- Once we had mi initial design we 
wrote CRC (class, responsibihty, and collaljorat.ion)^ cards 
for each of the classes in our desigrt (CRC cards are also 
described on page 79.) This design was reviewed by the 
product development team and their feedback was incorpo- 
rateti. 

The Object Testing Framework 

The design process produced an object -f>riented softwaic 
testing system that we named tiie ol>ject ti»sting framework 
(OTF). Altliougb this design is intended to test distributed 
ohject'hased software, it caj) also be usetl to test distributed, 
procedurally based client7ser\'er software, 'flie t)TF consists 
of tlu' classes shown in Fig, 2, The architecture of the 01T is 
such OkU there is a single master test control system (OTF 
management system in Pig. 2) tliat orchestrates nuuiing 
lesis i ti\ nndtiple systems under test. Tliis master system can 
also \n' a system under test. 



In the following design discussion, the term object can mean 
class or an instance of a class. It should be clear from the 
context of the discussion which is meant. 

OTF Management S system 

Hie OTF mai^gemein system consists of The six m^or 
classy: user uiterface, OTF controller, test suite configura- 
tion, test controllej, report generator, and database control- 
ler. This system provides the user interface that the software 
t^er interacts witii. Through this interface the tester speci- 
fies test configurations such as which client and ser\^er pro- 
granis wiU be running on which Sl'Ts. The OTF management 
s>^i:em takes the specified configurations and makes them 
a\'ailable to each of tJie SlTs. ensures tiiat the SiTs nm the 
specified tests, logs test data and results, and generates test 
reports. 

The main class in the OTF management system Is ttie OTF 
controller, wiiich serves as the delegator object. It takes 
requests from the user interface objecT and manages the 
activities of the test suite configmation. test contioUer, and 
report generator objects. The test suite configuration object 
is actually created by the OTF controller. For a new configu- 
ration the object will initialize firom the configiu'ation data 
pro\1dcd by the user interface. For a previously sijeciiled 
configuration, the object will initial ize from the database. 
Mer this objec! s conJIgumiion data has l>een set, its pri- 
maiy respon.sibility is to respond to configmation (Queries 
from the BUTs. 

The test controller has tJie overall responsibility for coordi- 
riating the running of tests on the SUTs. It provides the SITs 
witii a pointer to die test suite cc^nfigination object, syncluo- 
nizes the starting of tests, and passes status data and re- 
quests back to the OTF contioUen It also has die capability 
to log status data to the database via the database contioUer 

riie report generator, upon a reqtiest from the OTF control- 
ler, queries the <ialal>ase controller to assemble, filter, and 
format lest data uno user-specified test reports. Kaw^ test 
data is put into the ciatabase by each SlTFs TestEnvfronment 
object, wiiile test process status data is put into the data- 
base by the test controller as mentioned above. 

System under Test 

Each system tmder test (SI JT} contains fifteen classes. In 
normal operation, a SIT retrieves configuration data ft-om 
the OTF management system, and then, liasefl on that data, 
retrieves the specified tests from die management system. 
Since the SUT has tiie capability to build test exccutablos 
from source code, it can retrieve test source code and exe- 
cutables from tJie OTF management system. Once the test 
execut allies are in place and any spet ified test setup has 
been completed, the SIT waits tor a rnanagemeui system 
request to start ihi^ tests. When tJiis happens, the St-T is 
responsible for nirmlng the tests, logging status, test data, 
and restdts, and cleaning up upon test completion. 

The main object ui the SUT is the host daemon, wliicli is the 
SITs delegator object. The host daenmn takes requests 
frfun and forwards requests to the OTF nnuiagcnnent systerti 
and manages the activities of the setter upper, test executor^ 
cleaner upper, process controller, and TestEnvironment objects. 
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The overall responsibility^ of the setter upper, test executor, 
ancl cleaner upper objects is to manage how the tests aie 
run. These three objects collaborate with the builder, test 
distributor, checker, and factory TestCase objects to fomi the 
test maj^agen^ent stibsysteni shown in Fig. 2. The process 
controller aiid TestErvironment objects provide the infraslnic- 
tore for connecting the tests to the framework, These two 
objects collaborate with the TestCase objects to form the 
process management subsystem. 

Test Management Subsystem 

Til is stibsystem sets up and executes the tests and then 
cleans up aller the tests ha\x^ completed. Tlie setter upper is 
the object that controls lest setup. It is a low-level delegator 
that manages the activities of the builder, test distributor, 
checker, and factory- TestCase objects. Tlie test distributor is 
responsible for retrieving test execulables imd soiu ces from 
the OTF mai^Lagemem system^ Wl>en it retrieves som*ce 
code, the builder is responsible for generating test execul- 
ables from the code. How the tests are retrieved depends on 
the o\ erall system en\iromnent and resources available. A 
distributed file system, like NFS, could be used, or tlie tests 



could be remote copied from tlte ttiaJiagenient system to the 
SlIT. An important design consideration was to have a single 
repository for tests. This makes it easy to control changes to 
tests and is not intiiLsive on the SUTs. 

The checker provides the ability tcj customize test setup by 
invoking a user-written program that ( an ensure that ele- 
ments outside of tlie test environment are set up correctly. 
For example, it could check that NFS and DCE are running, 
that the display is set correctly, and so on. 

The factoiy' TestCase provides the setup proceditres tliat arise 
when testing a CORBA-based distribut efi <:)bject system. It 
creates the C.ORBA objects that reside in the CORBA-based 
sender TestCases and stores references to these objects for 
use by the client TestCases. The factory TestCase class inherits 
from the TestCase base class and the lest developer unites a 
class that inherits from the factor^' TestCase class. Tins allows 
the test developer to customize tlie factory TestCase function- 
alit^^ for a specific test. 

The test executor object stails the clieni TestCases tiirough 
the functionality inlierited from the TestCase base class. It 
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Objeet-Oriented Programnung 

Ob}ect-i]nent$fi pfogranvning ^ a set sf techniques for Dealing objects and as- 
se^ " *a a system jhm |ifuv>des a (Jes ired ^ " : t ^ : ^ : f 

to rr^fiipuiaie lis data 

cfews. or circurt compc : ^: 

as dtiegaior^. ^tit^. ot rmoe^ Messages are passed between ttm objects tc 

pfoduj^ the teired re$\Ms. 

The Bventuat goal of object-onentetl programming is to reduce tte cost of soft- 
ware devetapmejit by cmaiing reysahJe and mainrainabfe cotJe Tfiis is achieved 

by tisfng itiree futures of Qhim-or rented pfogrammmg: ern^sulation. polyrnor- 
p^ism, and inheriiance, Encapsulaiian coasists of data absifaction and da^ hid- 
ing. Data abstractton is a process of fsoJaiing attri bates or qua illies of something 
into an object moctel. With data hiding an object rnav contain its own pnvate data 
and methods, which it yses to perform its opera I ions. By using polvmorphism. an 
object's opefatjon may respond to many different types of data ie.g.. graphical and 
textual ], Finally, using inheritance, an object can inherft attributes from other 
objects The object may then only need to add the attributes, methods, and data 
structures that make it different from the object from which it inherited its basic 
characteristics 

For the design of the object testing framework described in the aEcomjjanying 
article, we used an object-or rented software design methodology called object 
modeling technique (OMT)- Tbrs methadDJogy provides a collection of techniques 
and notation for designmg an Dbjea-orrented application. 

One inrtpDrtant aspect of object-oriented design, or any software design, is decid- 
ing on who (i.e., module or ohjectj is responsible for doing what. A technique 
provided m OMT involves using an index cad lo represent nbjed classes. These 
cards are called CRC I class, respansibility. and cDllahoraiion) cards. The informa- 
tion on one of these cards includes rhe name of the class being described, a 
description of the problem the class is supposed to solve, and a list of other 
classes that provide servrcBS needed by the class being dehned 



also reports back to the host daemon the success or failure 
of a test st-art. 

The cleaiitT tipper cli^aris up after the tests have roni|>leted- 
This may iuchtde r€ni{j\1ng tejiiporary files, removing test 
executab!esj and so on. 

Process Management Subsystem 

The (wo main objects iji the [process nianagPtnent subsys- 
tem ai'e the process controller mui TestEnvironment objectis. 
The process controller has tlie overall responsibility to mon- 
itor aJl test-related processes on f he SUX ll van register or 
imregister processes, kilJ processes, and report [utH-ess sta- 
tus back to the host daemon. 

The TestEnvironment chiss pr(>\1des the test develrjper vrilh ^in 
application programming interface to the OTE It provides 
mediods for abordng tests, logging test data and results, 
cheeking for exceptions, getting etniromnent Viiriables, and 
S(J on. Tlie test developer gets access to iJiese inethotls 
tlirongb tlie base TestCase class, which has an association 
with the TestEnvironment class. 

Creating a test uwolves writing a class that inherits from 
either the client TestCase or server TestCase base classes. The 
initialization and setnt) binetionality for tlie lest would be 
int'hiderl in the testes constructor The cleanup reqniretl 
w^hen the test Is done is includiHi in the (k^stnicton Finally, 
an hnp lamentation for the inlierited run.bodyfl method is 
inctuded, wliicb is the test exetnttable that mns the test. The 



OTF API is made av'ailable throng the pointer to the TestEn- 
vironment class provided by the base TeMCase class. 

Itnpletnentation Approach 

Once the design was complete, an initial investigatioii was 
made to finri an existing system that matched the character- 
istic's of ihe design. UTien no system was found, an ana]>'sis 
was done to cietemiine the cost of implementing the new 
infrastructure. 

It quickly became obvious that the transition to the new 
infrastnicture wuuld have to be gradual since we did not 
want to impact tjie HP ORB Plusi>roducl release cycle. The 
flexibility provided by an object-oriented system enables 
^adnal migration and evolution through encapsulation, 
inheritance, and polymorpliism. Tests could be isolates I from 
the infrastniciure so that new tests could be developed and 
evolved without modification as the infrastructure evoh^ed. 
This flexibility fit nicely ^ith the realization that the time to 
replai^e the existing infrastmctiire exceeded an average 
product life cycle- 

Object-oriented encapsulation provided another advantage. 
Once some basic changes w^ere made to tiie existuig test 
infrttsl mcliire and tests had been con\ erted to the new 
object-oriented programming model, the existing test inii*a- 
structure could be used to simulate some aspects of the new 
infrastructure. This allowed our system testing efforts to 
benefit immediately from the features of the new test 
sj'stem. 

The development of the current version of the object testing 
framew^ork has taken place in two steps, witich have spamied 
tlu-ee releases of the HP OPB Plus product. At each step we 
have continued to apply the same design principles. This 
work is summarized in the following sections. 

First Step. Kot the first step, the goal was to consolidate the 
besi firat tices of tliree existing test in bust met tires into a 
single infrast riicnne that sittniiated as much of the m9,ior 
fujKtionality of tlic^ OTF as possible. Ho as not to impa^i the 
ongoing IIP ORB PIn.s s<)l'tware releases, another gui^il was 
to minimize thanges Ui existing test t-ode. This result t^d in 
an mfnistruciure that consisted of a layer cjf shell s€rii)ts on 
top of two existing test harness tools. This sigmficaiitly re- 
duced the effort needed to set up. administer, and update 
tin* network of systems that were used to system test thi* HP 
ORB Plus product, while the t«^sts continued to use existing 
APIs. It also confinned that our design w'as uidecd tr>'ing to 
solve the right problems. 

Second Step. Fortius step the goal was to deploy the test 
developers API to the OTF, The result was the implementa- 
tion of the C++ TestEnvironment and TestCase classes described 
above. 

Additional classes were designed to connect the TestEnviron- 
ment mid TestCase cljiisses to the existing infr^istructure, but 
their existence is hidden from the test developer. Tills pro- 
vides a stable API witliout liiuiting futtire enbancements to 
the inlraslriic lure. Once the new infrast met tire was deployed, 
we focused on porting existing tests to li. 

This framework has resultetl in minirtuil changes to existing 
tests and maximum intrrease in functitjnsLdity for the tests. 
Most of the work shnply involved taking existing code and 
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wrapping it in the appropriate class. Mi of our lesis have 
benefiteci Itoiii the features pro\idt*d hy tlve TestEnvironment 
aiitl TestCase classes and are insulated from ciianges to the 
franiework. 

At this stage of its dt»velopment the object testing frame- 
work allowed the reinoval of intrusive test eotle required by 
theoKl test APIs. For example, many test.s included eode 
tiiai allowed a test to be reexeeiiled for a spetvine time pe- 
riod. Thai cotte was renio%'ed from tlie tests beeause the 
sanie functionality is now provided by the framework. 

In atkiition to suiJ porting the design showTi in Fig. 2, our 
current implementation provides the following fmictionality: 

• Iteration. A test can he executed repetitively, eitJu'^r by spec- 
ifying a niiinher of iterations or the amouni of time. 

• ConteKC-sensiti\'e execution. The object testing fnunework 
behaves differently depending on how it is invoked. In the 
developer's environrneni it is transparent and does not 
affect test behavior. In the lesthig en\ironment it is boimd 
to Oie test system. For example, in the de%' eloper environ- 
ment, tlte C++ functions cerr iuxd caut go to the tenninal. but 
in the testing environment tltey go to a file and the test re- 
port j(nmiaJ restjet lively. This encoin'ages developers to put 
all existuig test.s inttt tlie framework because the tesi con- 
tinues to work the way it did before it was porterl 

• Simple naming sendee. A naming seiviee aHows the user to 
associate a symbolic name witJi a |jartieuiai" value such as 
the ijath name of a data file. In a distributed system, it is 
necessaiy hjr multiple jnocesses to share values that are 
obtained otttside of the system— for exainple, object 
references. 

• Autcjmatic capture of standard otitput streams cout and cerr. 
To simplify porting of existing tests, the cout and cerr 
streams are mapped to a lUe and the journal file 
respectively. 

■ Encapsulation of fimctions from the product under test. For 
example, the [jaits of CORBA used by tlie tests me encapsu- 
laterL As CORBA evolves and changes its t'++ language 
bindings, only a single t-opy of the bindings in the frame- 
work has to change. 

• inheritance and reuse. Inheritance allows the test case de- 
veloper lo dc'scribe similai" tests as a family of test cases 

de lived from a conmion class (which in tmii is derived from 
the TestCase class). In this case, polymon^iiism iUlow s test 
eode to be retised in multiple tests, while allowing changes 
to speclflic opemtioiis and data when needed. 

Example. Our experience with the cmrent fiamework has 
slu.Avti lluit the time to port existing applications tests to the 
new API is minimal. Fig. S shows mi example of how test 
code would look before and after beuig ported to tlie new 
test infrastnicnire. This example is an implementation of the 
chent for mi OMG COKBA program, which simply prints 
**hello, world," In this case, the t>lu"ase will be printed by the 
say^it methoci provided by the sen-er code. Tlie following 
descriprions iJOint out some of tlie cUfferences between the 
two source files. Tlie numbers associated with the tlesciip- 
tions correspond to the numbers in Bg, 3, 

L Fig. Sb shows poilions of the test code with TestCase and 
TestEnvirDnment instrumentation. Tliese classes m^e not in die 
code in Fig. 3a. 



2. Fig. 3b includes the class declaration and method defini- 
tions r)f a HBllaWorldlest class and a macro to register Uic <!pfi- 
nition with the TestEnvironment Tlie Hello WortdTest class is de- 
rived from die TsstCase base class. Fig. 3a source has no 
HelfoWerldTest class. 

3. The check_ev_ancl„ptr macro in the Fig. 3a source is greatly 
simplified in the Fig. 3b source, thanks to the TestEnvironmenfs 
print^exception and is_ni[ methods. 

4. Fig. 3a has a main limction. whereas in Fig. 3b, the main 
function is replaced by the HelloWar Idlest constructor, de- 
stnictor. and mrr_body methods. This structure allows the 
OTF to instantiate and run the test c*ode as needed. The 
constructor mid destnicior allows tlie test writer to separate 
out '^executc^ once'' code if desu-eth Tlie run_bodv method may 
be executed jiiore tluui once. 

6, Fig, 3a uses a file to store the object reference string 
created by Die serv^en (Use of files ts potentially difficult if 
Uie client and server aie on different machmes. ) Fig. 3b uses 
the TestEnvironments naming seivice to get the objt^ct refer- 
ence string, 

a hi Fig, 3li argc and argv are not available as input parame- 
ters and must be obtaitied ftom (he associated TestEnvtranment 

7. The irt return parameter of the main function in Fig. 3a is 
replaced by the TestErvifonment::Result of the run_bodv metliod 
in Fig. 3b. The effect is the same, to return the success or 
failure of the invocation. 

Next Steps. The following is a hst of items imder consider- 
ation for inijilementing the rest of the design and adding 
more fmictiontdity to tiie TestErvironment and TestCase classes. 

• User interi'ace class. We lire investigating the possibility of 
encapsulating a gratihical user interface that was designed 
for one t>f the existing test infrastrtictures. 

• Test controller class. Here again we are looking at encapsu- 
lating an existing test syiicluonization controlier. 

• Memor>^ leak detection. By adding tliis featine to the Test- 
Environment and TestCase classes, all tests vvill get this fimc- 
tionality through inheritance, 

• Integration wiUi mn-lime debugging. This will improve 
tracitvg an<l fault isolation in a distributed, multitiireacied 
environment. 

• Heterogeneous neti^'Orks. Tlie current object testing ftame- 
work handles netw orks of HP-l'X'-' systems only. We rieed to 
ext>and the fri^miework to handle other UNIX^ systems as 
well as PC operating systems. 

Summary 

The object testing framework is based on using object- 
oriented technology lo create a test infrastructure that is 
based on a number of snitiH, self-contained modules aiitl 
then develoiniig these modules in a \vay that allows the test- 
ing effort to jiroceed while the test infrastructure continues 
to evolve. Each step of the evolution results in a iLsable test 
infrastnicture that keeps the test effort online and provides 
critically needed support to product releases. 

In adthtion to our overall commitment to complete this pmj- 
ect. and a desire to see il used in oUier organizations in UV 
Involved in distributecJ object teclinology, we will continue 
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// Standard Om- (leaders 
fincltide dstreain.h:!» 
ftncJtHte cstriifgJi> 

// Header for CORBA HelloWorid sbje«i 
fin elude <^ellDType$.li)i> 
// list af iermr messages, 
extern char 'msgsCt 

// Scmple macro to check tcr gxceptious and valid 
tdefiire cbeck_ev_and_ptr(ev, pK eircoitel 
// Fifst check ior ejiceplioin. 
if ( ev.exceptiaMli \[ 
} 



G«rr « msgsferrcodel « " Excepliaii returned' « eiHll: \ 
felum Brrcode;^ 

//Neitl check far va:tid poinler 

rf(COReA:;Js.nmpirnf 

cerr « msgslerrcade] « "Pointer rs nulV « «ndl;\ 
return errcade: \ 

® 



int i 



KD 



mainlidt argc, char *argvl]) --^5) 



( 

C0R6A::£FivirDnnien1 ev; 

//Open 3 fRe which contains the oiiject leltrence siring for 
//the Hellc interface. Read the $lrtng. 

ifstresm frhello.instance'li: 

iinnf 

cefr« "Could not open \" hello instanceV file," « endl 

retutn 1; 

} 

} 

chat sorefnoZQ]; 
f » sof el; 

ifUru^ 

cerr « "Could not read the string if ied ab[eci reference" 
« "from lhe\"hellDjiistani:e\" filft." 
« end I; 
return Z; 

// Initialize Ihe CORBA envirnnenteni get pointer to the ORB. 

CORBAiGRB uar orb = CQRBA;;ORB_init(Brgc. argv, 

CORBA::HPORBid,ev); 

check, ev, and ptHeVp orb. 3); 

// Convert object reference string to object reference. 

CORBA::Dhject war hello olijref 
= arb->string to objectfsoref. ev}; 
check_ev._and_ptr(ev, hel|n„ol)jret 4]; 



}® 



// Stanttatd C** headers 

tin elude cfstreani.h> 

finclude <stiring h> 

// Header for CORBA Hello Worfii oHject 

fine Me c|ifllloTyp«sJ*h> 

y/ Header for Test Case object 
Itnclude "testcase^hh' 



-0 



// Lj^ of error ines&af e$. 
extern char *insgs(], 

//Sifi^ple tiiacro to check for exceptions and valid pttintees. 
#define c1ieck_ev_and ptiiev, ptj, eircodei 



// Check for ejtcepljon and valid pninter fT ) 

f f 
rf ( teprim except ionEevi II tejs_nillptr}i 
retuin [TestEnvi moment:: Result] -^ r | j 



(Test£Dvirflninflnt:ii£er_cf}de + err code I; 



//Dedaration of HeiloWerldTest class, 
class HeiloWorFdlest : public TestCase 

{ i . 

public: 

HelloWorldTestf); 
-HelloWorldTestil; 
TeslEnvironment;:Resitlt run_bodY4|; 

}; 

private: 

COHBA;:ORB_ptT orb- 
KelloWoHd ptr hello: 
chsr 'message: 



■^ 



J® 

<z) 



t 
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D£ C LA RE_TEST C AS E_ FA CTO RY I K e 1 1 oWa r I dTest ): 

// OefinitJon of HelloWorldTest constructor. 

// The falls wtng pieces of the test are considered set up. 

HelloWorldTest ::HelloWE]rldTest(j 

{ 

COR B A: :Environnient ev; 

// Get the object reference string for 

//the Hello Inieilace from tho test environment. 

string sofef ^ !e. get obje£;i sirFngf^'hiello mstance"]: ^ 



// Initialize the CORBA environment, get pointer to ORB 

orb = C0RBA::ORB rnillteargc, te.argv, CORBA;:HPDRBid, ev}: 

check ev and ptrjev, orb, 3\: 

// Convert ob|ecl reference string to otijecl reference^ 
C0RBA::Obfect vnr helJo.objref 

= orb- >si ring to objecttsoref.c^strfKflv); 
check^ev and pir[ev. hello obiref, 41; 

// Narrow the COBRA:: Object object reference iu a Hello World one. 
hello ^HclloWodd:: narrawfhello ohjref, evh 
check ev and pirfev. hello. 5}: 
COBRA:: release(hellfl objref]; 



COHBA::strrng f reef message!; 
CDRBA::releaset hello); 
CDRBA::release(hello„objrerh 
C{)RBA::release(orb); 

I 



CORBA::siriiig free (mess age); 

CORBAireFeaselheUo); 

CORBAiireleaselorhl, 

J 



(al 



Ibi 



Fi|f. 3, ill) Test vmU^ hvUirv being ported to the objecf testjng Eramework. (b) Tlie same test after bmig porterl. 



to participati? in standards organisations such as OMG and 
X/Ol>en to follow Llir work iliai i.s hHn^ rinne in the art*a of 
lesUf^g. To tiaU\ wt' havt^ ev;iJiUited ami firovitU'tl ft'i^dljack 
to the X/Open Consortium aiid have a representalivt^ nioni- 
iQTing thr ac^tiviiy ;tt OMG, 
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A New, Lightweight Fetal Telemetry 
System 

The HP Series 50 T fetal telemetry system combines both external and 
internal monitoring of the fetus in a small, lightweight transmitter that is 
easy and comfortable for the patient to carry It is useful for monitoring in 
labor, monitoring of high-risk patients, monitoring in transit antepartum 
nonstress testing, and monitoring in the bath, 

by Aiidreas Boos, Michelle Houghton Jagger, GCinter W, Paret, and Jiirgen W. Hansmann 



Electronic fetal monitoring rerords fetal Iieart rate, uterine 
aeti\ity, and fetal movements onto a trace, allowing ohstetri- 
cal fiiiiif ians to better assess fetaJ well-being and the ade- 
Qnacy of fetal oxygenation. 

In today's high-tech hospital en\1roninent It is easy to over- 
look the fact dial the m^^jority of pregnant wonaeii who are 
admitted t(j the hospital to give biitli are not sick, bnt are 
expcrienchig a natiirid event, tlie delivery of 1 heir babies. 
Widi this in nund, many hospilaJs worldwide arc iuixioiis to 
create a more friendly cn\ironnienl in their labor tmd dehv- 
eiy departments by reducing the amomit of technology at 
the tmtient's l>eflsitle. Tliis redncr.icjii in techntilogy caj^ iires- 
ent a problem. Although palients waiil a more natural en%1- 
romnent, llie nmsing staff still wants to be al>le to oversee 
fetal well-being during labor aJul deliveiy. There has to be a 
balance between these two goals, and monitoring of the 
fetns \ia telemetry offers a solution. 

Telemetry monitoring of die fetus involves connecting a 
patient to a radio frequenc:y transmitter, which she is able to 
cany (Fig. 1), Tins transmits the fetid uiforniation via QllF 
radio frequencies to a receiver coimccted to a fetal monitor. 
Tlie monitor records the inronnation as if the patient were 



1 




Fig, 1. The HP Heries W T feUi telemetn^ sy^: ji. i j . 
lightweight aiid coinfortable iiy wear. 



connected dirccdy I o it. Tlic fetal monitor and receiver can 
be j)laced in a central kjc^ition for the itursing stall lo view 
the fetal iidbrmation, and nvi:'i\ nor be in tjie fjatienis room, 
thereby reduchig the perceplion of teelmology at her bedside. 

Fetai monitoring with telemetry has been available for the 
past ten years. Until now, these telemetry systems only al- 
low^ed either external monitoring of the tetiis such as ultra- 
somid detection of the feial heaii rate, or liUenial methods 
such as direct inorutoriiig of the fetal heart rate by means of 
a scalp electrode. Veiy few systems offered both of these 
methods, and those that did were large and hea\y for the 
patient to carry, and had a very low battery life. 

The llewlett-Fackard Series 50 T fetal lelemetr\' system 
(HP Mi:310A) is a new lightweight, space-saving telemetry 
system. It com hi ties both exteniid and internal monitoruig 
of tiie fetus la a small, lightweight transmitter that is easy 
and comforiable for the patient to cany. Because the padent 
is not connected directly to the fetal monitor, a atiml:>er of 
additional cUiucid applications can be addressed, iru^hiding 
monitoring hi labor, monitoring of high-risk patients, moni- 
toring in transit, tuuep^mimi notistress testing, and monitor- 
ing iit 1 he bath. 

Monitoring in Labor. Tlie tecitnobgy used in the HP Serie^s 
50 T ensures that die product can be used in the very eaiil- 
est stages of labor, before the membranes ha\ e niptnred, 
irj.]\i up to ant I timing the second stage of labor when the 
hiihy is l^eiitg fleUvered. Tliis means diat the patient is free 
to move around from tlie onset of labor, whde a rehable, 
continuous fetal trace is available for overseeing fetal welJ- 
being, Allo^^ing the patient to walk around can be beneficial 
for the patient, especially when the delivery- is long, and can 
e\ en help rednc^e the pain of her contracUons. 

Monitoring of High-Risk Patients. UTien a high-risk patient has 
been adniittetl to the hospitid tor obsenadon before the birth 
of her ijaljy it is often deshable to provide contmiiotis moni- 
toring of the baby lo ensure its w ell-being. However, this is 
not normally practicaJ because it would mean connecting 
die patient to a fetal monitor and conftnhig her to bed for 
long periods of time. I-shig the HP Series 50 T fetal teleme- 
try^ system, the patient is free to w^alk aromicl, ai\d tlie nurs- 
ing staiT has a constant over\iew of fetal well-being. 
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Monitoring in Transit Besides being compatible with all HP 
fetal monitors produced since 1^2. rhe HP S^^ries 50 T fetal 
telemetiy sjrstem can use the staiidard transducers of the 
HP Series 50 family of feial nioiHtors. Tlus is useful for ex- 
ample, if an emefgencj' occurs and the patient needs to be 
transported to the o|)erating n>om for a Ca^sarean section. 
In certain countries it is a legal requirement to provide con- 
tinuous monitoring of the fetus from the time the parient 
leaves her room to the deli\'ery of the bal»y. By disconnect- 
ing the transducers from the fetal monitor and connecting 
them to the transmitter of the HP Series 50 X continuous, 
ujiinternjpTe<i monitoring of the fetus is ensured. 

Antepartum Nonstress Testing. Nonstress testing Is performed 
dining the patient s rt^gular visit to the clinic or hospital dur- 
ing her pregnancy. By allow ing the patieot to aJiilmiate and 
record the fetal heart rate \aa uhrasound. nonstress testing 
can be performed witltont haviitg to confine tlie patient to 
bed. thereby allowing her freedom of movement and tlie 
abihty to sociahze with the other patients. 

Monitoring in the Bath, h is beconung more common for a 
patient to he gi\ en a batli during labor to help reduce die 
pain of her contractioi^. Before the intioduction of the HP 
Series 50 T feral telemetry^ system, tliere was tio safe way of 
providing a contunious overview of fetaJ weU-bcing w^hilc 
lire patient rchLxcd in the bath. This me^mt \itai information 
on [\\c fetus could be missed. By usuig the HP Series 50 T in 
cotyunction with the standard waterii^it "^bliie" ttUrasound 
and TOCOt trat^sducers from the HP Series 50 family of 
fetal monitors, tlie musing staff can he assured of a continu- 
ous recording of tetal inf orntation even when the patient 
decides to take a l^ath. 

Fetal Monitoring Measuring Methods and Principles 

The parameters ineasurt'd iii fetal moniiojltig applicatiotvs 
aie fetal heart rate, fetal movemeiils, and matemai labor 
activity. 

lite fetal heart: rate is cuntimiously monitore<i on a beat-to- 
beat basis and rec^orded together with the niatenial lUerine 
activity and optionally the fetal niovenients ort a fetal trace 
recorder. 

There aie tw^o established methods to measure the fetal 
heart rate. One is to process die fetal ECG by using a fetal 
scalp electrode and measuring the time distmice between 
two QRS cc^nplexes. This method is invasive and can only 
be used if the membranes have ruptured and the* fetttJ scali> 
is accessible to attach the scalji ECG eiectrodt*. Tliis is true 
only for the last few^ hours before delivery. 

The second method of measuring fetal iiearl rate is to calcu- 
late the heajl rate from a Dopjiler-shifted tiltrasound signal 
by itieasuring the time flistance [>etween two signal com- 
Ijiexes resultmg from fetal heart m^ Jtion. A l-MHz pulsed 
ultrijsomui signal is emitted towartls tJie felal hemi aJitl tlie 
uRrasountl waves aie Doppler shifted by the moving parts of 
tile liciut and reflectecL Tlie reflected iind Doppler-shifled 
sigiud is received again atul demodulated by a i-Mliz clock 



t TOCO IS an abbreviation for tocoarapn or locodyriamamater. an instmi^inffor measuring 
antf racDiding ttie expiifsive force af utertne coniracnnos m labor U is usuiillv wrjtren m 
uppernaiiQ letters like the abbreviaiions foi fh@ athar feial measuring methods: US = ulira- 
sound. ECG ^ elecipocarcfiogrsm. I UP = mtraulBf ina pressure. 



signaJ. After fiitertng and ampli^cation (by approximately 80 
to 106 dB), only the low-frequency Doppler-shiited signals in 
the range of 100 to 500 Hz remain. These signals are fed to a 
loudspeaker to give the user audible feedback about the 
correct transducer positioning. Compared to the relatively 
simple algorithms needed for the heart-rate calculation from 
tlie ECG signal (the ECG signal is a well^leSned. easy-lo- 
recognize signal) the algorithm for the ultrasound signal is 
much more complex, Tlie ultrasound Doppler signab con- 
tain a lot of different pulses as a result of reflections from 
dilferent moving partii of the heart during one heart period. 
These pulses change their shapes and ampMtudes depending 
on the angle between the ultrasound beam and Uie heart. 
Therefore, a simple peak-searching algorithm cannot accu- 
rately calculate the fetal heart rate from the idtrasoimd Dop- 
pler signal on a beat-to-beat basis, so a more complex algo- 
rithm using the antocorrelation function of ilte itltra^sound 
signal is used. The auto congelation function determines the 
similatity betv^eeti all tlie pulses of two consecutive heart- 
beats. The distance between two poLnt:s of Mgttest similarity 
is then used to calculate the actual fetal heart rate. This 
mediod reaches a heart rate trace qiialit>' comparable to that 
of a ti"ace derived from an EC*G signal (the ECG signal is 
recognized as the "gold"" standard for fetal lieml rate moni- 
toring). The advantage of the ultniSfimul Doppler method is 
that it is a noniuvasive method and can be used froiti the 
twentieth week of gestation up to deUver>' and no direct 
access to the fetus is necessary, 

F'etal movemeiUs can also be detected front the uhrasouiul 
Doppler signal. The fetal movenient signals differ from the 
Doppler heart rate signal in tiiat they have a much higher 
aJii|>litude and a lower frequency. Tite higher amplitude is 
liecause of the 1 Jigger size of llie moving aieas (e.g.. the fetal 
mms an(i legs) and the low^er frequency is because of the 
lower velocity of the fetal movements compared with those 
of the fetal heait. 

Foi* measuring maternal labor activity (uterine activity), 
there are two estahlishefl methods. The IVP (intrauterine 
pressttre) method measures, ils the name imiilies, the atiso- 
lute pressure in the utems by inserting a pressure trans- 
ducer into the uterine cavit;^^ THs can be a p recalibrated 
jjreasure sensor niomited m a cathetei' tip or a saline-solu- 
tion-filled cathtHer with a i>res2^ure sensor connected out- 
side. TJtis method is invasive to die mother mid can only be 
used if the membranes are ruptttred. The second method is 
an external noninvasive method (external Tf )CC)) which 
measures die relative hardness of the abdominal wall and 
the underlying uterme muscle. This mcthoil provides rela- 
tive valncs and not absohite pressures like the IL'P catheten 
Tlie presstire sensor in botii transducers is based on a resis- 
tive biidge with four [)ressure-sensitive elements. The bridge 
gives a liigh i^ressm-e sensitivity but needs ditTerential ex- 
citation and a differential signal ampllHen 

Wireless Data IVansmJssion 

There iu*e ntitny possihilirtps frjr wireless data transmission 
from one location to imr>ihcr Each tnethod lias its indiviciua! 
advantages and dLsad vantages when analyzed for a specific 
aptilication. We looker! at infrared and radio frcfiueticy 
iransuiission and cvjdtiated their advantages and disadvan- 
tages for the fetal telentetiy application. 
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In&ared light L^ widely used as a data transmission method 
becausi* of its simplicity and the fact that no regulatoiy 
approvals are necessary. However, for ilie fetal f elenletly 
applic'ation. its use is not possible hetaiisp the t nuisniltting 
rangt^ is very' limited and secure data transmission is only 
possible on a iine-ol-sight basis. This means that the trans- 
mitter cannot be covered by clothes or a bed cover and the 
transmission range is limited to one room. These conditions 
cannot be giiainnleed during labor and deliver^' because tiie 
patient can wiilk artiund mid change her posit itni freely. Aix- 
olher disadvantage from the ieclatical standpoint is the rela- 
tively high power consmnption of an infrared system when 
ased in a <'oritinuons (ransniission mode, which is necessaiy 
for eontinnou-s monitoring. 

Radio frequency transmission, another very widespread 
transmission method, overcomes most of the problems of 
infrared transniission wlien it is designed caret ully and aji 
appropriate frequency range is chosen. Fre(iuencies helow 
100 MHz will result in large antenna dimensions (the wave- 
length is 3 meters at 10(5 MHz) if high efluMency ift neede<l 
(this is a strong requirement because of the battery-o|>erated 
transmitter). On tiie other hand, frequencies abo\e 1 (7Hz 
result in a wavelength (<30 cm) at wliich anteimas become 
more axKl more dh'ectional, signal generation lequires more 
space mu\ power, .ijui it takes special processes to build 
printed circuit boards that can handle such high frequencies. 

A mi^joj' disadvaiitage of radio frequency systems is that 
indiviflual apjiroval for eacli countrj' is required and mairy 
different requirements and boundaries are given by iill the 
national iaws. These reqnu ements must be bilfilled tu obtairv 
country approvals and should be covered I by one design to 
avoid many special product options. Thus, the resulting de- 
sign must meet the most stringent sjiecitlcation of all the 
different national standards for eacli requirement. A positive 
aspect for Eurcjpe is the upcoming hanrtoiiization within the 
Einxjpean Comuuuiity (.EC) where one standard v^ill be used 
for all European conmiunity members. At the moment, Ger- 
many, France, anti Italy have convened this standard into 
national law (others will follow^ a limit of two years is 
given for all countries to convert this standard into national 
law ). This means diat for these countries only one standard 
is valid. 

Tlie decision was made to use radio frequency data trans- 
mission. 

The follo\^'ing items and specifications have been set up for 
a telenietr>' design to meet all the rcquiiements for world- 
wide use: 

• The frequency must be configurable in the range of 405 MHz 
to 512 MHz. 

• The radio fi^etjuenc^y (RF] power must be adjustable in the 
range of 1 m\\ to <10 mW. 

• The spurious emissions nmst be < —36 dBm for frequencies 
< 1 GHz and < -30 dBm for frequencies > 1 GHz world- 
wide, and must be < —54 dBm in Eiut)pe it^ the frequency 
ranges 42 to 68 MHz. 87 to 1 IS MHz. 162 to 230 MHz, and 
470 to 862 MHz. 

• Tlie RF bmidwldth nius! be < 25 kHz worldwide and sl>ould 
be < 12.5 kHz for Japajx (25 kHz would be acceptable but ls 
not preferred) 

• Tlie transmitter nmst be capable of sending a special idenri- 
ficarion erode aftei' power-up for Japan. 



• The RF stability* over temperature ( - 10 to ^^dK") and hu- 
midity (5 to 95% R.H.) must be better tlian ±3.5 kHz for the 
U.S.A. and better than ±2.5 kHz for Europe and Asia. 

However, to design and build a radio frequency traiusmitter 
that meets all the above specifications requires extensive 
engineering manpower, lesting* an<! design iterations. There- 
fore, we decided to reuse an t^xisling RF transmitter and 
receiver for our fetal telemetry application. 

a\ftei" examining all possibilities, we found a good candidate 
in tlie RF jjajts of the HP M140() adult ECG telemeUy sys- 
tem. The RF pai1i> of tliis telemetry system had all tlie ap- 
provals needed, and lis highly modular design CRF parts 
were strictly separated from Uie apphcation-speciiic ele- 
ments) allowed us to pick up only those paits needed for 
our fetal application. The only modification needed was a 
small adaptation of the receivers digital control software 
(which pro\ides automatic frequency control — AFC — and 
the bitstieam recovery of tlie digitid protocol used to trans- 
fer the ECG waves). T^iis software had lo be jnodified to 
execute only the AFC function when used for ihe fetal appli- 
cation and ntjl die liitslrt^am recnveTy. 1 1 wiis even possible 
to mo(iiIy the soft wj^u*e so il)ai il automatically switches to 
the correct application so riiat the same software can be 
used for the aduh telemetry system and the Series 50 T. By 
reusing the adult RF i^aits, we dramatically reduced the en- 
gineenng effort and only had to concentrate on the band- 
width specification (which is mainly determined by the mod- 
ulation) and the special Japanese fD code. 

The reused parts ai'e the vo)tage<ontrolled cr>'stal oscillator 
("\^CXQ) in tJie trajismitter and as tiie local oscillator on the 
receiver side, the line amplifier as a receiver RF [ueanipli- 
fier, the receiver module, and all antemia paits (antemias, 
combiners, splitters, power tees). 

Data Transmissioit and RF Modulation 

To get low ad^iacent chamiel emission, the — 6-dB RF band- 
width should ncjt be wider than ± 8 kHz for a 25-kHz chan- 
nel spacing. This gi%^es a mai'gin of ±4 kHz for frequency 
drifts caused by temperature, himiidity. and aging. 

The adult ECG telemeti^^ s^^'stem uses digital Gaussian mini* 
mum shift keying frequency modulation (GMSK-Fi\i ) witii a 
9f30043iiys data rate. Tlie resulting - t>dB RF bimdwidUi is 
approximately ± 8 kHz. 

Because the processuig powder needed to calculate the heart 
rate ft'oni the ultrasound Doppler signal is not available in 
the telemetr>^ transmitter, the ultrasound Doppler signal is 
transmitted to a recetver> which feeds it to a coiuiected fetal 
monitor, which does all the signal processing. Ttie telemeOy 
system ouly acts as a v^ireless analog from end for the feial 
moniton The HP Series 50 fetal monitors sample the signals 
at a l.t>kHz sample rate with 12-biT resolution. To transmit 
the iiltrasomid signal as a digital bitstieam, the requireti data 
rate is 12 bits x 1(300 samples/'s = 10200 bit.s/H for the ultra- 
sound signal alone. Togetlier vrith Uie uterine aeti\ity signal 
and tile necessmy framing and checksum overhead a mini- 
mmn data rate of 22 kbits/s is required. This data rate does 
not include any redundancy needed for enor correction. 

To fit into the 25-kHz channel bai^dwidtb, this data rate nnisi 
be compressed to 9600 bits/s. Tliis requires highl\ 'Sophisti- 
cated data compression circiutiT. Tlie data stream resulting 
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from a sampled iiltiasoimd Doppler signal does not contam 
as fiiuch redundancy as the ECG. which does not change 
rapidly except for Hie short duration of the ECG QRS pylse. 
To fit into a 12.5-kIlz channel spacing an additional data 
reduction down to 480() bits per second is needed. 

We decided to transmit the heart rate sjgiml (ultrasonnd 
Doppler or ECG i with stantlard direct FM modtilation. The 
uterine activity signal together with some status signals — 
banerj' stattis. nurse call fimcrion, serial number, and trans- 
ducer modes (ultrasound or ECG and external TOCO or 
TUP) — are inunsniitted as a digital bitstream. This itiforaia' 
tion is transmitted four times per second. Everj- data block 
is secured with an B-bit citeckstmi (CRC). A data block al- 
ways starts with the serial number of the trajtsmitten This 
serial nmnber, which is the same for tlie Transmitter and the 
conesponding receiver, is used by the receiver to synchio- 
nize itself with the datastream and to verify that the data is 
comkig from its o\mi UfUisiniTTen This ensures thai signals 
from two different palieuts using the same RF frequency are 
not mixed. The overall data rate for the digittil transmitted 
sigiials is 200 bits/s. This data stream is transmitted as a 
frequency shift keying (FSK) signal with a 1600- Hz signal for 
a logic and a 240(}-Hz signal for a logic L This signal, 
added to the heait rate signal, fretjuency motiulates the RF 
earlier. The amplitude of the cotnposite signal detemtuies 
the required RF IjLuulwidtb and can easily be adapted to 
meet the 12.5-kHz chatuiel pacing requirements. 

RF Bandwidth 

The resullijig RF bandwicith can be estimated as follows. 
The modulation signal is composed of two components: (1) 
the ultrasouufi Iloppler signal or tlie ECG signal and (2) Lhe 
FSK subciUTJer signaK The mocktlation spectmm is iihis- 
trated in Fig. 2. 

The RF FM modtilator has a sensitivity of l.B kHzA', which is 
tiie specification of the reused RF oscillator from tlie aduit 
ECG telcmetiy system. Tile ulirasourui signal has a band- 
width BW|f - 50U Hz and an miiplilude of 1.875 X^.p which 
produces an RF carrier shift of L6 x 1.875 = 3.0 kHz. Tlie 
correspomUng modtilation index is p = frequency 
shift ^ moduiaiiiig IVetiueney ^ 3,0 kHz/500 flz = G. The KCC^ 
^gnal has a bantiwidih BWjf - iOD Hz and a cairiei sliift of 
:5 kHz, so tlie modulation index is [5 = 3.0 kHz/I 00 Hz = 30. 

Tlie FSK signal has as its highest frequency a 2.4-kHz sinu- 
soidal earner. lis amjilitude produces an RF earner shift of 
1.5 kHz. The modulation index is p = LB kHz/2,4 kHz = 
0.625. 
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Fig, 2. .M<jriulatiou signal ^peilnim ul ilu- HP Series 50 T fetaJ 
UHeiuetry sysieitt transmitter. 



For a modtiiadon index less than one the RF bandi/^idth is 
appraxin^ately BWjf = 2BW|f. Only the Bessel funciions of 
orders and 1 have significant values (>0.01 j. so the\^ repre- 
sent 9f**Kj of tlie RF energ>'. or in other words, ouiside this 
band\%idth the signal is 20 dB do\\n from the maximum ai 
center fi"equency. Thus, the -20-dB RF bandwidtli of the 
FSK carrier is 2 x 2.4 kHz - 4-8 kHz. For a handiAldth where 
the Signal is 40 dB tlown {9fl,iWtj of the RF energy- is within 
this bandmdth } the Bessel function of order 2 is also of iiv 
terest and the - 4t)-dB RF bandwidth of the FSK carrier is 
4x2.4 kHz ^9.6 kHz. 

For a moditiatlon index greater than one. the RF bandwidth 
is approximately BW^f = 2(P+l)BWrf for a bandwidth where 
the signal is 20 dB down. For a bandwidth where the signal 
is 40 dB down tliis bandwidtli doubles again: BW^ ^ 
4(P+l)BWif. 

With a modulation index of ii the ultrasound signtd pro- 
duces an RF bandwidtli of BW^ ( -20-dB) = 2(6+1)500 H/. = 
14 X 500 Hz - 7 kHz or B\\\( { - 40-dB) = 4{ 6+ 1)500 Hz - 
28x500 Hz- 14 kHz. 

Witli a modulation index of 30, the ECG signal has ai\ RF 
bandwidth of BWrf ( - 20-dB) = 2(30+1 ) 100 Hz = 0.2 kHz or 
BWrf ( -40-dB) - 4(30-hl)100 Hz = 12.4 kHz. 

Thus, the overall RF l.iandwidth is mainly detennined by the 
tiltrasomid signal or tlie ECCt signal and not by the FSK 
signal. 

The amphtude ratio betw^een the heart rate signal and the 
FSK sigtiiU TiVas t^hosen so that as the field strength at the 
receiver input goes down, the signal-to-noise ratio of the 
FSK signal decreiises before the heai1 rate signal is affected. 
The receiver detects bit errors in the digital data streani and 
suppresses the heart t^te output signals to the fetal monitor 
when errors occur. Thus, the fetal motiitor always shows 
either \lw correct iieaii rate values or no value, l)Ut never 
displays wrong values, which may lead to a misdiagnosis. 

Telemetry IVansmitter 

Fig. '] shows the components of the HP Series 50 T fetal 
telemetry systtmi. 

A tiigli priority for the telemetry system design was to sup- 
port the same transducers as tised by the HP Hei-ics 50 fetal 
monitors. Customers ran use the transducers they normally 
use with their fetal monitors and can switch between stim- 
dard nuinitoring and telemetry monitoring simply by replug- 
ging the transducer connectors from mi& device to the other. 
Repogitionmg and reapplying the transducers on the patieni 
are not necessaiy and the switch f^an he perfonned in a few 
seconds. This cfmipatibility was no problem with the ultra- 
somid and uteri up activity transducers, but the fetal monitor 
ECG transducer required more detailed investigation to 
design circuitry to handle this transducer in the telemetty^ 
transmitter. 

lite HP Ml 357 A fetal ECG transducer is an acdve imtrsducer 
in which the complete ECG prea!rip lifter and its floating 
power sulkily are incorporated \u tiie trausdnciT legplate. 
Since the telemetiy transmitter is baUery powered, ibis 
floating, higlily isolated preamiilifter isoverdesignetl I or 
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Fig- 3* TraiiBmitter^ trajiMucers, m\d receiver of ihe IIP Smi^a 50 T 

fetid lelemet.ry j^ysteni. 

lelernetr>^ use. However, it is niaiidatory for use on a mains- 
powered fetal monitor, since i>atient safety requires all 
trail Sfi lie ers that have direct contact with iJie patient % ia 
eiectrical conducting electrodes to be floating. 

The M1357A transducer reqtiires a lOV peak-to-ijeak power 
supply signal ^ith a frequency between 100 ajul 250 kHx. 
Tlie ECG signal is transferred on the same wires by power 
load niociulaticm, which means that the transducer vaiies its 
load on I he driving circuit nith the ani]jlitude of the ECG 
signal. A circuit liad tu be designed that is capable of dn\1ng 
the HP MPi57A IraEisdueer with a lOV peak-to-pcak signal at 
250 kHz, sensing the load cuiTent, and operating from a 5V 
supply. A bridge driving circihi btiill wilt) digital 74AC14 
inverters nmning at 250 kHz was found rn l?e rrajjable of 
delivering the required diive signal with enough powei^ to 
supply die transducer. The load current is sensed i>y a 5-ohm 
resistor in the grountl connection of the 74AC14 drivers. 
Fig. 4 shows the ECG transducer driver circuit. 

A tiiajor consideration w^hen designing a telemetiy system is 
the power consumption of the transmitter. It runs from bat- 
teries and therefore a go^d is to make the operaring time as 
long as possible with one set of batteries. The low-power 
design of the HP Series 50 T transniitter extends the operat- 
ing tiine to more than 40 hours of continuous operating v^ith 
idtrasomid and external TOCO transducers connected. Tlie 
power source is tlu^ee A A alkaline cells. This is two to three 
times longer than competitive fetal teiemeto- systems. \Mien 
used with NiCd batteries, the operating time Is comparable 
with competitive systems, but the weight of the HP Series 
50 T transmitter is only half that of the liglitest compeutive 
transmitter 

In addition to weight and operating time, another major as- 
pect of telemetry' systeiu design is tr^msmitter size. To get 
the best use of the available volume, the IIP Series 50 T 
transmitter uses donble-skieti surface moimt teclmology on 
the printed circuit boaids. This lednces tlie board space by 
40 to 509(v compaied to single-sifled technology' antl makes 
tlie HP Series 50 T transmitter the .smallest aj\il lightest of all 
competitive fetal telemetiy transmitters. 



Fjg. 5 is a block diagram showhig all major functions of the 
transmitter. A mirror on t roller is the heart of tlie (ransntitten 
Tliis seemed to be the best soimion, cor\sidering all of the 
required features such as Japanese ID code transmission 
after power-nj), nurse call function, serial number handhng, 
analog liaidware control depending tipon the type of trans- 
dncer (ultrasound or teial ECKJ, TOCO orlL:?), batteiy status, 
and CRC cidcnlation for every data frame, Tfie microcontrol- 
ler gives mtjre flexibility than an ASIC and the deveiopment 
time was shoiter. With an appropriate controller it is pos- 
sible to execute the fetal niovernent detection algorithm in 
the transmitter, thereby saving transmissiott capacity of the 
RF channel by transmitting only tlie movement detection bit 
instead of the fetal movement Do|>pler signal. 

Microcontroller Features 

We chose the Mitstibishi M37702-M2 16-bit controller. This 
cont. roller has tme 1 G-bit processing power and many inte- 
grated peripheral functions, and is low in cost. It, has 512 
bytes of internal KAiM and i6K bytes of ROM. There ^u'e 
eight independent 16-bit timers. Five of these have li^eir in- 
puts and outputs accessible on pins, caji individually select 
the in])ut chick from a predivldert and can rim in several 
modes including timer, co miter, pulse width modulator, one- 
shot, free-numuig, or triggered from mput pins or software. 
Tlie controller also has an independent watchdog timer, 
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Fig. 4. HP M1357A ECG transducer driver. 
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Fig. 5. HP Series 50 T fetal tekmeto* 
system transmitter block diagram. 



eiglit channels of S-bit analog-to-rligilal converters, and two 
indepctidont synrhroiious or asjnchronous serial {^ommnni- 
calioii rluuinels. The patkage is a phLstie quad tlarpack with 
80 pins. Tlie rich set of integrated peripherals on the conti'ol- 
ler chip allowed us to save a lot of hanlware that wrnilfl 
otherwiye t>e needed oulside tlie controller. 

Tlip controller is available witJi S^MHk:, If^-MHz, or 25-MTiz 
input clock speed, Thr i>racessing power needed in the HP 
Series 50 T transniitter allows a reduction of the clock fre- 
quency to 2 MIlz. When nutrung w\\h the 2-MHz input clock 
and all peripheral limctions active, the M87702 controller 
consumes only L') inA with a 5V iiower supply. 

Tlii'ee timers (one in timer nn)de, two in one-shot mode) are 
used to produce the gating signals for tlu^ fjulsed ulli'a.sound 
Doppler cliaimeL Fig. 6 shows the resulting gating signals. 
With a sound velocity of 1500 m/s in hiinian tissue, the re- 
sultirtg tiltrascamtj sensitivity over depth can he calculated. 
The minununi depth is delenninc^d hy the delay time be- 
[ weert the end of the ultriisoimd Iransmil luilse tunl llu^ start 
of the receive gate i>ulse, v^hich is U^ in Fig. ih With f;i = 32 
M^^ f^min ^ n''>(JO X 10=1 X 32 X 10" V^ = 24 nun. Tlte maxi' 
aiujn <ie|)th is determined hy the time b(H ween the start of 
ll^ie transniil gate and the end of the receive gate, which is to 
+ t;i + t4 :r 224 ^s, Tlie depi h is then dnias = ( 1500 x Itf * 
x224 X lO^^^)/2 = IfiS mm. The factor of 2 in these calcula- 
tions results from the fact that lite tiilrjitsouiid wave ijrojja- 
g^iU's fust ttjwards the reflecting object located at depth d 
ant! then hack agahi 10 the transducejr. 



Tvfro limers are used to produce clock signals needed in the 
ECG anrpliricrand ihe TtK'O transducer excitation circuitry. 
One timer is used to produce the ltjO(^/:^4tM»-liz FSK signal. 
One timer in coimt mode, together with an external first- 
order sigUKi-deh a modulator ( one comparator and one Dip- 
Hop), forms a 12-hit iutalog-lo-digital converter for Ihe uter- 
ine activity signal. 
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One serial comntiinication chaimel m synchronous mo<le is 
used to control a serial EEPROM to si ore I he serial niinitier, 
some calibration constants, tJie country optiori codes, and 
the power-up ID code for Japa:^. The second seri^d commu- 
nication port is used as a production and semce pod to 
read out intemaJ signals, to program the EEPROM, and to 
send messages during power-up if self-test failures are 
delected. 

Tlie A-to-D converters are used to monitor the batteiy volt- 
age, to measure the ultrasound Doppier or ECG signal am- 
plitude to control fhr signal gain, to measure the fetal move- 
ment signal ajnpiitttde, and to rneasiire some test voltages 
during the power-up selt-tests. 

Literine Activity Measurement Circuitry 

The uterine acti\1ty transducers are buitt with four pressure- 
sensitive resistors in a bridge configuration. This bridge con- 
figmation requires a differential excitation voltage and a 
differential sensing amplifier. The bridge resistors ai-e in the 
range of 300 to lOOfJ ohms. The requirement of compatibility 
with star^dard fetal monitor trmisducers did not allow the 
use of a new transducei* with a lugher impedance to reduce 
die drive power The lUP tnuisducers are active and need a 
drive voltage of at least 5Vdc or 5 Vac at > i kllz. The residt- 
in^ power consumption for the 300-ohni type is then P ~ 
V^R = 25/300 - 83.3 mW, 

A circuit can be designed that reduces this power level to 
45 mW. Tlie disadvantage is a sensitivity reduction by b dB, 



tiiat is, the sensitivity is halved, litis can be compensated by 
doubling the gain of the sensing amtilifier A oVac excitation 
at l.B kHz (half the repetition frequency of the pulsed Liltra- 
sound Doppier to avoid interference between the TOCO 
flrive ciriiilrr> i^ncl tiie uKr^^ound demodulator) was chosen 
instead of a sijnpler dc drive circuit Ijecause low-jjower op- 
erational Jimplitlers nnming on 5V or less with liigh dc preci- 
sion have not been available for reasonable prices. Tlie labor 
aciivity signal, whicii is a signal with a band\^1dth from dc to 
<2 Hz, is obtained by a s>Tichronous demodulator Ruuiing 
at L6 kHz and a low-pass filter By usuig ac excitation, die 
sense amplifier can be buih with simple and inexpensive 
TL062A ampimers. 

Fig, 7 shows the implementation of this circuitiy. The TOCO 
excitation appUcs power (+5V and ground) for ttie first half 
of a IbOO-Ilz square wave (50% duty cycle). During die sec- 
ond half, the excitation drive is sv^itched off. Ttiis halves the 
power c:onsiimption of the TOCO transducer resistive bridge. 
A differentitil ampliHer senses the bridge signal, amplifies it, 
and c onvcrf s the differential sign^il into a single-ended sig- 
nal. The input capacitors settle to the bridge output voltage 
during the active drive phase of the excitation driver and 
discharge to a middle value during the nondriv ing pha;se 
tln^ough the bridge resistors. In this way the sensing ampli- 
fier input picks up a 1600-Hz signal with liaJf the amplitttde 
compai'cd to a full- bridge excitation driver. The signals are 
illustrated in Fig. 8. 
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Fig. 7. TOCO drivei" and sense 
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Fig, 8. TOCO s\gi\B.l wavprorms. (a) ExcitaTlan signal. Cb) Sense 
ampliflar diffftrennal inpiit (low bridge differential sigrtaJ). 
(c) Sense amplifier differential iiipui Cliigii bridge differential 
signal), (d) Sense ampiiiier dlEfereniiid input with irue bridge 
exciUtion. 



Japanese ID Code 

Japanese radio freqiiencj' laws require that a special idendfi* 
caf ion code be transmitted event^ time the transmitter is 
switched on. The code biistream is modulated on a subcar- 
rier wiih a speed of 1200 or 2400 bits^s or is direct FSK or 
GMSK modulation of the radio frequenci^' carrier sipial ai 
1200, 2400. or 4SO0 bits's for FSK and 20(H). 4000. or 8000 
bits^s for (rMSK mo<hdation. The bit rate must i^e accurate 
within a loleraiice of ± 2(K) ppni. The code is composed of 
(1) > 100 bits of alternating ones and zeros. (2) a r31-bit tnax- 
iniuni-lengtli pseudorandom noise code sequence. (*3} 51 ID 
code bits (provided by tlie regulatory agency, this code is 
unique for every- transmitter and contains infomtation about 
the device manufacturer and the product, and a unique se- 
rial number that has nothing to do \^ilh I lie nomtal product 
serial number), (4 ) a 12-bit checksutii calculated from the 51 
code bits by a special polynominal divisiort. 

In the HP Series 50 T transmitter, this code is stored in the 
EEPROM during the production finid test. Dtuing a pow- 
er-up sequence, this code is read by the transmitter niicro- 
contiTjIler and transmitted as a 1200-bit/s FSK signal before 
starting normal transmission. The code in the EEPROM is 
also secured by a clit'ckfsinn. If tJtis checksum is coniipted, 
tlie transminei' will not start uorniai d'ansmission as re- 
quiied by Ihe regu!aior>' agency. This feature is only active 
for Japanese options (also stored hi the EEPROM) and is 
ignored for all other countries. 



Power Supply 

An essential part of a battery powered handheld device Is 
the power supply. The fetal telenietr>^ trausniitter is designed 
to mn w ith three AA-si^e alkaline batteries or rechaigeable 
NiCd accumulators. The new and mure enviroiunental 
frietitUy NiMH a<'cuniulators are also supported. 

Tlie mput voltage is from 2,5 to 4,8 volts. The powder supply 
must provide the followmg output voltages: 

• +5V. Main supply voltage for all digital and tnost analog 
circuits 

• +2.5V, Virtual grmmd for 5V single-supply analog tire nils 

• +8.5V. Sui>i>ly for sf>me operatiojial amplifiers and the ultra- 
soimd receiver preamplifier 

• -:i5V. Negative Htipijly Tor a few operational amplifiers to 
increase the ssgiuil fly nam ic range. 

Tlie power supply is a switched-ntode type delivering a 
stable ( ± 1%) +5V oiitjiut from the batteries. All other volt- 
ages, which need only a fev\' milliiimperes, are btult with 
charge pmnps or simple buffered voltage disiders. Tlie 
switched -mode power supply Rms at 250 kHz in a pulse 
width uTodulalion mode, The250-kJIz switching fi"t*quency 
has the advantage that only small inductors are needed. Part 
of tlie power supply is also the main cr^stal-cont rolled clock 
Dsciiiator mnning at 4 MHz. All othei^ clock signals ai*e de- 
rived from this rnaster clock. The osfillatf>r atid the power 
supijly iue tlesigned to stati wiih input V4>ltages as km- as 
2.0V. The efficiency of the power supply varies between 70% 
for low^ (2.5V) input v^oltages and S'3ii with a 4.5\' input. 
Fig, is a diagram ui the iTansmiuer power supi)l>; 



Modulation Circuits 

The modulalion circuits have a twofold responsibility. One is 
controlling the RF bandwidth vvitii its amphtude and fre- 
quency chfUBCterLstics and tluis ntamtaining conformity 
with RF regulatory requirements. The other is making the 
best use of the available RF bandwidth to get I he best pos- 
sible signal-to-noise ratio for llie trar^sioilted signals. 

Fig> 10 shows the modulation chcuits. The circuitry consists 
of tliree subcircuits: a programmable -gain ampliTier, a lim- 
iter^ and a low-pass FSK shaping filter. 

The programmable -gain amplifier acyusls Uh' hisirt rale sig- 
nal amtditudi' to a value that corresponds [^ » iio' ., i jf the max- 
intuin aUow'ahle RFl>andwidth. The margin uf 40%is loac- 
conunodate the often rapidly c hanging signal amplitude, 
especially for the tdtrasound DojJider signal. The gain of the 
amplifier is controlled by a regulator algorithm implemented 
in the M37702 contnjller. The cniTcnt signal amplitude is 
measured with one of the Integrated A-to-D converter chan- 
nels, and from this value an appropriate gain is c aJculated 
for the prtJgtununaljle-gain amplifier. Tliis amtilifier consists 
t>f an operatioiial amijlifier with an 8-hit multiplying IVIo-A 
converter in its feetll>ack path. So as not to tiiange the gain 
ttjo much during one liean period (which could lead to a 
wrong heart rate calculation for the affected beat), the new 
gain value is artiustcfl linearly over tw^o seconds. Therefore, 
the 4tM margin is t>rovidcKl so that tlie amplifier does not 
overdrive the signal too often. 

Tlie limiter circuit following the programmable-gain ampli- 
fier clips the sigtial to well-defined limits in the case of a 
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suddenly increasing input signal ro I he progi*ammable-gam 
amplifier. The low-]iass filter, which also acts as a bandpass 
filter and a sununing amplifier for the square wave FSK sig- 
nal, removes the overtones resulting firom the clipping ajid 
thereby ensures that the modulation has a well-defined RF 
banchvidlh. 

Telemetry Heceiver 

The recovery of the digital bitsticam in the FSK signal is the 
main task of the receiver. The FSK signal is extracted fron; 



the composite signal (FSK and heart rate signal) by an analog 
bandpass filter \\ith 1400-Hz and 2fiOO-Hz comer frequencies. 
Tiie recovered sinusoidal FSK signal is converted into a 
square wave by a comparator, AH subsequent recovery tasks 
aie implemented m a Mitsubishi M37702-M2 microcontroller 
(tl^e same l.\i>e as used in the transmitter). 

Digital data recovery can be divided into tw^o niaui tasks: 
FSK signal demodulation (recovering the single bits from 
tlie 1600/24UO~Iiz input signal j and synclironization vvith the 
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iransmitted data frames. Fig. 11 shows tiie FSK signal de- 
iTKxiulation scheme* which is completely hnplemejUed in the 

microconiroller. 

The pulse period measuring circuitry' is composed of two 

microcontroMer timers. The first timer is configured as a 
retriggerable 250-|is one-shot and the second is corilignred 
for pulse period nieasureTnent. The incoming FSK square 
wave signal rirsi toners riie cine-shtit, which suppresses 
very short periods l>etween two posith^e edges in the incom- 
ing signal and triggers the pulse period measurement tinier 
The timer generates an interrupt whenever a new pulse 
period measurement is complete. For noise rejec lion, the 
period values are low-pass filtered and all period values that 
are outside die limiis for a I6t)0-Hz or 24t>0-Hz inpui Tre- 
quency are rejetled. This greatly improves the signal re<^ov- 
ery for noisy input signals. 

The integrate and dump block sums all of the incoming 
l>eriod values. Alter five millisecoiids, which is one bit time, 
the sum is reset by a dump signal dehvered by the bit clock 
recovery digital phiise-locked loop. Before resets a coniptua- 
tor decides if the receiveil bil was a logic one or a zero. 

The phase-locked loop block recovers the bit clock from tlie 
Lncomuig data stream and generates the sample and dump 
signals, wliich aie phase syiTclir ionized viith the incoming 
data clock. Only ini^ut sequences consisting of one or two 
equal bit^ (bit patterns OKJ, 101, 0110, and 1001) are used for 
tlie phase tracking. The one- or two-bit detector produces a 
reference signd wiienever one of the four bit patterns is 
derecied in I lie it icon ling bits! ream. The delettor measures 
Uietinie between changes hi rhe incoming j)enod signals 
and checks to see if tJiis time falls within tJu^ Uinits for one 
or two bit times (4 to 6 nis for one bit m\d P to 1 1 nis for two 
bits). 

1\) extract the individual frames frtjm Uw n'vnxcrcd Ini- 
St real n^ I he structure sliuwn F\g. 12 is used. The jci DVereci 
bits are sfufled into anO-lni-fleep serial iji, parallel out shift 
register, wliich is ihe leiigih of tvnv frame. A etjcnplele frnnie 
can be stored in tiiis sliifl register- and ail of its bits juialyzed 
at once. 

TJie header search algcjridmi l(jf)ks for a valid header p:ut*^ni 
ill bit positions *:!<> to 48. The lieatk'r pattern m deriveil bum 
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Fig* 12,^ Data stroani n*cov€*ry in dio^ HP S*>ries 5i) T fetal lelemetty 
swsiF.'ni roceiver. 

tlie system seild nnmber (iransinilter ajid receiver liave tlie 
same serial ntmxlicr stored in their EE PROMS). Bits 49 and 
50 are ttsed to identify whetlier a franie lias been scrambled 
before transmission. Tlie scramtding is done if tiie original 
frame did not contain enough single or double bit patterns 
for the clock recoveiy phase-locked loop. The scrambling is 
done by inverting every second Int in the friunc. 

IJ^ a valifi header {original or seranibled as indicated by tlie 
scrambling identification bits) Is found, the complete frame 
is checked f{>r a good CRC pattern by the €R(' calculation 
block. If tiie CRC is OK. the complete frame is deassemblcd 
into the origin^il information iuid saved, tiie header search is 
disabled for a complete frame, and a synchronization fione 
flag is strt. 

If the CRC i.s not OK for more tlum tw*^ frames, the 1 leader 
searcfi is enabled again ami rhe syntiuonization lost Hag Ls 
set, Tfie lime since tJie last conect C*RC is nieasui^efl by a bit 
coimten If more than 10(1 liits me receivecl without a contact 
ehecksinn, the synch t on l/ation |>rocess is resiaited. 

Test Strategy 

To ensure maxinmm reliability and saTety, extensive self- 
tesLsare executed eacli time the transmitter and rerei\er 
are powered up. Not only are the t^asy-lo-test digiUil iiurl.^ 
checked, hul also most r^f ilie fijialtig hardware. TIun is tittne 
by genet at ing artificial signals, feeding them into the differ - 
enl analog signal paths antl mt^asuriitg the response of each 
jiath. All these liisks are performed by the <>nbi>ard M:^7702 
cfuil nailers in the traitsmi tier and llie receiver. The results 
obtained ar<^ checketl against limits. If any deflation is cle- 
tected, a clear failure message is sent out over die integrated 
service pori {RS-2S2 line) to assist in troui)lesli(jotlng, and 
the (ransmilhT or receiver tries to restari. This ensures that 
a faulty <levice does not go into nf>rmal ot>erati(ai and that 
no incorrect data m transmitted or displayed by the attached 
fetal niottittir. Tests have sliowii tliat ai>oiit HQ'>U of all part 
shons or opens iue tleiet table in tiie analog processing 
pEirts. Tilts is a very Ingli number for power-up analoi^ tests. 
Achieving sut-h a high enor detect rate was only possible 
through the use of a powerful microcontroller. The software 
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for self 'test and service support is about 40% of the com- 
plete software package. 

Production testing of the transmitter aiid receiver is divided 
into two parts: single component or board testing before 
final assembly and final test of the completely assembled 
de\ice. 

The loaded boards arc tested by im auloiTkatic test system. 
Connection to the circuitiy on a board is made by a needle 
befl adapter which allows stimulation and tnetisurement of 
every net aztd evety component on the board. The goal of 
thLs test is to venfy tliat alJ t:omt)onents are loaded correc tly 
and have tJie tight values. If a com|>onent fails, the tester 
reijoits the component, its location and the rietected failure. 
For surface mount boards, most failmes are bail stjlder 
joints and shorts between puis. To test complex paits like 
RAAls, A-tchD converters, microprocessor, and microcon- 
trollers, a hbrary model of the part describing its behavior 
on predefined stimuli is required. To check for good solder 
jouUs, a model that toggles eveiy phi of a component as 
hiput or output is sufficient. IMortunately, such a model 
was not available for the M37702 controller, which is an 
8f 1-pin de\1ce in a quad fiat package. To test this component, 
we implemented special softw^are m the controller itself, 
which can be activated by the test system by pulling a pin to 
+5V, Tliis pin is t^hecked by llie sofiware during the pow- 
er-up cycle and the speciaJ test software is entered if tiie pin 
is pulled high. Tlie .special software minors Tt\e inpm pins \o 
the output jjins. The test system only has to at)]>ly a test pat- 
tern to the inputs and tiien check for tliLs pattern on the cor- 
responchiig output nets. 

Tlie HP Series 50 T fetal telejiieti>' system uses the same 
final test equipment as the Series 50 fetal monitors. Most of 
the filial specification tests are similar^ or idenrical to the 
Series 50 fetal monitor tests. Tl^erefore. we implemented a 
production and sendee interface identical to those of the 
fetal mom tors. Only a few tests had to be added to co\"er the 
I elemetr> -specific specifications. The test itself is hi^lily 
automated and controlie<i by a workstation computer. This 
computer controls the measurement etiuipment, i>et1orms 
the measiu'ements, prints the results and stores tlie results 
in a database. Tliis allows continuous production process 
control by calculating the Cpk value (a value that desciilies 
tile product ion process capabilities) for each test specifica- 
tion to check the stability of all production processes. This 
also makes it possible to detect test result drift resulting 
from part changes before a test result completely fails the 
specification. This process control prr^cedme is siip]>orted 
by ISO 9001 and EN 46001 certification rules, and it really 
increases the product quality and st^bilit>', which the cus- 
tomer can directly see. 

Support Strategy 

The tlF Series 50 T fetal telemetry system can be iLsed as a 
.standalone unit with a local antenna, or the receiver can be 
comiecied to an existing anteima systent. When comiected 
to an antenna system the coverage area is increjised. The 
design of anteima systems and the connectiot\ of the Series 
50 T to an antenna system is the respoasibihty of HP cus- 
tomer engineers. For standalone systems tlie system is de- 
signed to be uistalled by tlie customer (tjlug-aiid-playj. 



The acceptance tests needed to ensure proper functionahty 
are built iiito the firmware mifl can easily be t>erfomied by 
the eustomen Jn case tjf a^iy problems the customer caJi caU 
the HP medical response center The response center engi- 
neer has the ability to give troubleshooting instiiictions and 
finii tlie defective assemi>ly. 

All of the low-fiequency assemblies can be replaced onsite 
or on the repau' bench. Tire EF' Jissembhes (400 to 500 MHz) 
can only be repaired on the repair bench because high-preci- 
sion RF instruments are needed to do RF tT'ouble shooting. 
SpeciiU service software is available to assist m trouble- 
shooting. This softwaie provides check data for transmission, 
monitors field strength, and transfer's serial numbers when 
needed for repair. 

Tlie support features were implemented witli minimal effort 
because the support requirements were chscussed with field 
support peraonnel and their inputs were considered by R&h 
hi the design phase. 

Error Detection and Display 

The HP Series 50 T is designed to show any software mal- 
function through the use of ret! LEDs in a certain sequence, 
Haidwaj e failures can be troubleshol by the response center 
by telephone by following certain procedures and noting the 
results. 

The p! ocessor botutis of both tlte I tansmltter and die re- 
ceiver mn self-test routines after poweron to test hardware 
functionality and software integrtty. After power-on, the re- 
ceiver switches on all LEDs for one second to test them, and 
then returns to nonnal otieration. If the power-on test fails, 
aU LEDs stay lit. indicating an enor condition. After 
power-on. the transmitter switches on a red LED hidtlen 
behind the positive connection on the middle batteiy inside 
the baltei7 compart.nienL This LBl) stays on foi^ three sec- 
onds, and if everything works it is switched oft If there are 
any errors this LED stays lit . All this visible information is 
veiy' helpful to the response center engineer checking for 
system malfunctions \1a telepiione \\ith the customer. A 
defective section can be located m a veiy' short lime with 
high accuracyj helping to ensure low cost of ownership for 
tlie user 

TYoubleshooting Tools 

Tioubleshooting tools are built into the system to pro\1de an 
internal error log. reporting on settings and failures, Tliis log 
can be accessed by software nmning on a stattdard PC via 
an RS-232 coimection to the receiver or uajisniittej'. The 
sottware log is detailed and hi eludes an interpretation of 
each error message, so no manual is required. 

Should a fetaJ telemeti^ system need repair, the sothvaie to 
test the internal ftmctioiLs and do simple troubleshooting is 
built into the unit. On the re|)air bench, during onsite repair, 
or during biomedical testing, it is only necessai^^ to connect 
the system to a standmd PC and start the senlce software 
to have the built-in troubleshooting help available. The con- 
nection between the PC and the transmitter or receiver is a 
ij-wire RS-232 interface. All transmitter and receiver re- 
sponses can be tested. For hardwaie replace merits, such as 
tlie transmitter or receiver CFLT board, the serial number of 
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the ^'sieni needs to be written to the new board using the 
service sofli»\'are. To avoid Uping errors, we decided to read 

the serial number (mm the nondefecthe unit (transmitter or 
receher) and transfer il to the new iinji ( receiver or trans^ 
mirter). In the case of imemiitteni failures the PC' rtinmng 
the senice software can be connected to the s>^teiii and the 
PC' can collect the error log oveniigliJ. Tlie SfrTvice software 
is designed to be totally self-dest ribing ^iili all re|KJrtetl 
niess^es interpreted, thereby avoiding error cocies. which 
require error tables to find the problem description. The 
main screen of the service software shows the following 
information: 



***** M1310A Service Software eevAOiO * 


* * * =J: 


* M A IN :^1 E N L 


* 


* - Program S/N to Transmitter 


^ 


* - Program S/N to Receiver 


* 


-^ ~ Power On SeLftest 


* 


^ - Show ktsi eirojV warnings 


* 


* - Chetk Trai^ymirter 


* 


* - Check Receiver 


* 


* - Read SerNuni and Re\1sions 


* 


'^ - Reset Senal Number 


* 


'^ - Read comitr>" inftirmaiion 


* 


=*= ~ EXIT 


^ 


^ 


* 


* * * * * * * * * -t * * * -i: ^- 5^ :!; :}: ^^ * * -ii t ^ 


=i- * * =^ 


* Select with <up>, <dowTi>, <enter> 


^^ 


* * :^ ^ :«c ^ :p :p ^ :i: 5p :|: Mi iR Hi if: ^li !|i 'A' ^ H^ t- -i^ 4- 


::: :!: :fr :|: 



Tlie following represents the ftrst screen to program the 
serial nuiuher to the transmit I er: 



-'It 
* 

■j; =tf :|; 

5|J ^ * 



* ^^ * M1310A Senice Software Rev,A.01. 00 'i' ^ * ^= 
Program S/N to T^mismitter 

~ follow the steps <ENTER> 
^> (i) plug cable to REC^EIVER 

(2) READ S/N from RECEIVER 
RCVR-S/Nis: 

(3) phig caijle to TRANSMITTER 
rliecldn^ XMTR~S/N 

( 4 ) WRITE S/N to TRANSMnTEK 
KMTR-S/N is : 






3|3 :|< 3ii « « 4C H^ :|; ij: ^ 



' Rctuni loMAIN 

ii ;|r * j|: .$ ^^ :^ :^ ^ ifi :|i 

Select with <up>, <down>, <enter> 



The iiser is guided step-by-step throu^ the pro-am; no 
manual is needed. 

Installation Acreptajice 

After it^talhog the fetal ielemeit>' s^'stem the performance 
of the system should [ye tested. Tlie installation acceptance 
test is built-in. (h'c*rall transniission between the transmit ter. 
receiver, and feLal monitor is checked by creating a synthetic 
signal. This is a simple operation that can be done by the 
customer. 

Tlie s>Tid>eiic signal for the acceptance test is generated in 
tlie ti^ansmitter and shows a test patteni on the fetal moni- 
tor One heart rate trjm.sducer and one TOCO transducer can 
be comiected to the transmitter, and the acceptance test 
gives the appropriate output for the txansducers connected. 
Tiie acceptance test is started by pushing and holding down 
the nui'se call button while switcliing on the transmitter 
power The test nms a.s long as the nurse call button is 
pusheti On the fetal monitor a heart rate is mcLLsured and a 
TOCO triangular waveform shows the proper functioning of 
the overall sy stent Tliis acceptance test verifies the overall 
ti'atisniission from the transmittei" to the receiver \1a radio 
frequencies and the transmission fron^ the receiver to the 
fetal monitor \1a cable connection. If all the signals are 
transmitted as expected the fetal telemetry qualhy is 
acceptable. 

Tlie acceptance test Is designeri to avoid nwy need for exter- 
nal test tools or measurenient ei^uipmeni. Because it is easy 
to perfonn and no external eqintimeni is needed, this tes! 
helps save installation costs and reduces cost of ownership, 
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Zero Bias Detector Diodes for the 
RF/ID Market 



Hewlett-Packard's newest silicon detector diodes were developed to meet 
the requirements for receiver service in radio frequency identification 
tags. These requirements include portabilitv. small size, long life, and low 
cost. 

by Rolando K. Buted 



Itei^dng of products and senlces is critical In today's highly 
iSOItlpetitive aiKl rapifUy growitig world of manufacturing 
and service industries. To succeed in tliese industries, accu- 
rate and timely iufonnation is required. 

Two widely used tracking methods me bat' code readers and 
magnetic stripe. j\Ithoiigli commonplace, they are both lim- 
ited ir^ tjieir range and their operating en\ironment. F'or ex- 
ample, [mr codes require a direct Ihie of sight within a few 
inches and a relatively clean a[id benign envir(>iuri*^ii! to 
operate reliably. 

In contrast, a mdio frequency identification (RF/ID ) system 
uses radio signals to conununicate. JJne of sight is not 
needed and the system can operate in hostile environments 
characterized by water, oil, paint, ajul dirt, ll can even be 
used for conununicarion through cement, glass, wood, or 
other nonmetallic materials. These wireless systems are 
bemg successfully used to identify^ and track cattle, house- 
hold pets, cai*s piissing throngli toll booths, supermarket 
caits, i-ailroad cars, and personnel entering and lea\dng 
secure facilities. 

An RF/fD system is composed of tw^o components: a reader 
(interrogator), which contains both transmitter/receiver and 
deeoder/coinrol modules, aiKl a tag (transponder), winch 
tyi">ically contains an antenna and a leceiver circuit. Since a 
system normally has only a few interrogatoi's but many tags* 
the most severe design consti'aints are on the tag. These 
constrahUs mcludc portal7iht>^, small size, long life, and low 
cost, liewiett-Packard's newest silicon detector diodes 
(IISMS-285x) were developed to address these constraints. 

RF/ID Technology 

RF/ID tags can be active or passive. Active tags liave an on- 
board powder source { a battery) so that less power is needed 
from the reader and usually have a longer read range. How- 
ever they liave a limited life sp^in and are generally more 
expensive to mannfacture. 

Passive tags do not need a separate external power soiu*ce. 
They derive their operating powder from the energy^ sent, by 
the interrogator. Passive tags are lighter anct cheaper than 
active t^igs and have viiiually imlimited iifetinie. Some i>as- 
sive tags contain a batterj^ to maintain internal jnemory in- 
formation in reacL/write applications. The trade-off is thai 
passive tags have a shorter read range than active tags and 



require a much higher-powered reader to supply the energy 
needed to operate tliem. 

RF/ID tags can be read-only or read/wTite. Read-only tags, as 
the name implies, can only be read, but can be read millions 
of times. Read/w^rite tags allow the data stored in them to be 
altered in adtiition lo l>ei[tg read. 

Whether the tag is passive or active, read-only or read/write, 
it requires a receiver circnit. Receiver circuits can be of two 
types: superheterodyne or crj^stal video (Fig. 1). Becanse 
the superheterodyne receiver contains RF S:md low noise 
amplifiers, its detection sensitivity Ls typically -150 cLBm. 
The crystal \^ideo receiver, on the other Itand, is limited to 
only al)out -55 dBrn. However, it. is simpler and nnicli 
cheaper than tiie superheterodyne receiver, so the RF/ID 
industiy has adopted it for use in tags. The superheterodyne 
receiver is used in mteiTogators. 

The crystal video receiver of Rg. I can take ditferem forms, 
depending on the application. Four common configurations 
are shown m Fig. 2. The smgle-diode circuits offer simplicity 
and low cost, w^hereas the voltage doubter circuits pro\ide a 
Mgher output for a given input. Each type can be designed 
with conventional n-type Schottk>^ dioiles or zero biased 
p-tyi^e Schottky thodes, tf n-ty]:je diodes are used, an external 
dc bias source is needed for fletecticni operation at low input 
power levels (<1 mW) because of the low saturation cur- 
rent. The P"type zero bias chode does not need a bias source 
because it has a relatively lugh saturation cunent. In addi- 
tion, it offers the low^est possible cost, size, and complexity, 
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Fig, 1- (a) SuperheterodjTie receiver. In EF/ID applications, this 
receiver type is used matrily in inrerrogaiors. (b) Crystal video 
FPceiv^r This t\pe h used in RF/ID tags. 
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Backscatter RF/ID System§ 



4M+r!n3*T \'^ir^o iijo?*^^r5!"»" ^Vl| IS one aspect of intelligefit vehide-highway 

e of the use of RF/ID i^hnsbgy m a practical 
ecns 5fe be^ng mtegrated into e^ecironfc lot I 
co1!«jttDn at bntJges so rbat lolls can bs deducted from sn acctwm &y tisincf infor- 

jyipj ..- r*-'^ri r, = - , ^^1^^^ iH the vehicti's wiftdsftreld 

Or nents of these svstems is thai the sisttonarv feadei 

lintBrrogatorj be able to discriminate between individual lags passing the toll 
bootti without tnterfereni^ from othei tags Of other transmittefs that may ^ 
operating at the $3^^ frequK^cy, Backsattef n-iodulatian tedinology is one 
method that can be used for such an appltcatlon 

A block diagram ot a typical transponder (tag) for backscatter technology is shown 
in Fig 1 The tntermgator (feadar) sends a fnodufated RF signal that ts received by 
the tag. The Schottky diode detector demodulates the signal and transfers the 
data m the digital circuits of the tag The radar cross sectson of the tag is changed 

by a frequency shtft keving encoder end switch driver so that the reflected [back- 
scattered 1 signal from the tag is modulated and ultimately detected by the reader's 
receiver antenna, Thus, ajmrnunication between the tag and reader is established. 

By using baekscatter rechnology, mtarferencs from rtearby transmitters tan be 
avoided, smce the reader controls the frequency of operation and can shift it if 
nearby transmitters are operaimg at the same frequency Also, the reflected signal 
strength from the tag is proportional to the incident interrogator signal, so tags 
outside the incident beam focus area will reflect a weaker signal that the rgader 
antenna can reject. 



Such a backscatter tag car^ have leadt/wnte carsbi'+'et tt^sr allow ftexiWe dtgita^ 
fomtats h ca« also contain varioys tag in* r used in othef IVHS 

applications A specific mimmum field stre / 3iit the Schottty 

detecli3f diode into foiward bias so that the rag does no! backscatter until the 
inierrogatDf Et^rial arKJ F^--=3r,E t::*- =ro ro-oi jo^j ^^^ minim 7"^-^ *^^ ■^wef 
requlremertts of the leg 
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Bg. I- Typical tran5pander h\u£k diagram tar backsc attar Rf/ID technoSiDfly, 



aiid usuaDy exhibits the lowest flicker noise. It is therefore 
Uie diode of clioice for RF tag applications. 

The performance of kui HF/TD system is directly related to 
tlie freqtieticy nmge in which it is used. The higher the fre- 
quency, tfie faster the data transfer rale and the longer the 
rearl/ write range. Tfie tag's ntpture wimlt^H' is more focused 
at higher freqnency. Metals absorb h>wTre(iuency signals 
more than high-fretjuency signfilSj wherejts obscuring mate- 
Hals such as dii1 anct grease absort) liigf^frequenc\\' signals 
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y H 
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more tiian low frequency signals. Most RF/ID systems oper- 
ate in thi'ee basic frequency ranges. Tlie liigh-frequeiicy 
ranges include 85(] to 950 MIIz ajid 24 to 2.5 GHz, Tlie low^ 
fiequency range is 100 £0 501 J kHz, close to the range of AM 
radio statioris. Some appUeations, sucti as auto loll collec- 
tion, also use 5.8G GHz and 10.5 GHz. 

Device Theory 

A Sc hot iky 1 Mode is simply a metal layer deposited on a 
semiconthictor such as silicon. Tf) iuif^rove its perfomiajiee 
and reliability, it can be passi^ated with silicon ihoxide or 
silir:^on nitride or both. 

The equivalent cireuh of a Schottky diode is shown in Fig, 3, 
along with package ijarasitic elements, hi the diode clni)^ R^ 
represents the series resistance of the diode, winch includes 
bulk iwid contact resistances. Junction ca[iacitanc*e Cj is 
determined to a fii'st-order apprfjximation by the metal used, 
tlie silicon doping, and the active area. Rj is the junction 
resistance, often caJled the \4deo resistance R^=, and is a 
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Fig. a, I uffpri^iit ci^'st^il video ret^^^ivtr cimiifiirmtknvs. Ca) %c»ro 

bias Srhuttky dit^des, (b) Cmw^iitioiialn-typoSc'houky diodOvS, 



Fig. 3* This iniMlel desciibes an S0T-2:i paekfiged Srhottky ditide 
lu 10 UHii Willi gumi acturatry 
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iimctioii of tlip totaJ rurreni flo'wing thrfiugh I he device. I^>w 
Cj, Rv and R^^ are desired for an efficieot detec^tor diode. 

The total curreni I Hf>\^ iiig tlirough a Sthottlcy diode is given 
by: 



I = [4exp(V|,/nV,) - l| . 



where I^ is the diorle saturation current, \'\^ is the \^o)tage 
ac'io,ss tlie Sclic:ittk>' i>iu"rier, n is ttie ideality fac fc^r, imd V^ is 
file tliemi^iJ \i dtage. Tlie vohage across the Sdujttky biuiier 
is equal to an applii^d \ oltage Vy niiuus any voltagv* dr{>p 
acrtJss the series resistance R^, that is, Vj^ = V^ ~ lE^. At low 
bias levels, R^ can be neglected, so V^ ^ V^ . 



The \ideo resistance is Rv ^ 
Rv = nlVl . 



dVt/dL so for small I^ 



F(jr the zero bias inmdltion, \a = 0, at rtHjin tetnperalute 
wil h u = L tlie \1cleo ipsistaiic^e siui])hfles to: 

Rv = 0i)26/ls. 

By increasing Ij^, the video resistance of the diode at zero 
bias Is Jiiininiized. I^ is increased by proper selection of the 
metal lyijc and the semiconductor doping. For sihcon, jvtyjie 
geiu^rally gives a liigher I^ than n-t>^>e. However, p-tyi^e sili- 
con has higher K^ tiiaji n lyp^" silicon with die sanie doping. 
Increasing the silicon dtJi^ing to lower tl^e R^ also increases 
Cj, which degrades lite detector performance. N-tyi^e 
Schfinky diodes are seen in mixer applications because of 
the lower R^ and tlie fact that Rv Ciui be kept low by using 
high local oscillator drive levels. 

Design Goals 

An important perfonnattce charact.erisTic used lo describe 
\ideo detector diodes is voltage sensitivity, or y. This param- 
eter specifies the slope of the cnne of ontjiut \idpo voltage 
versus input signal power, Uiat is: 

Vo = yPin ■ 

Neglectitig pai'asitic and reflection tosses, voltage sensiti\iiy 
can be defined as: 

where P is ihe cunerU sensitivity and has a theoretical 
value ^ of 21) AAV. losing the diode equaUon (with ideality 
factor n = 1): 

ai/fJV = I/Q.026 . 
Therefore, 

Y = 0.52/1 . 

For zei-o bias detectors, y = 0-52 /I^, 

This shnple aitalysis of a perfect detector gives a poor 
approximation to the actual data on existing diodes. To 
bruig the analysis closer to realiiy, effects c^f diotle jiuiction 
capacitance, diode series i*esistance, load resistance, and 
reflection loss most be considerecf 

Diode C apac ltd Pioe and Resistance, In most cases, the Junction 
impedance associated with Ry and Cj is much greater than 



RsT especially at low frequencies. However, at high frequen- 
cies, the jimction impedance is reduced so diat the RF 
power dissipated in R^ is compaiable to that of die Jimction. 
Incorporating the effects of the diode capacitance and resis- 
tance on the current sensitivity,^ the voltage sensitivity for 
die zero laas diode liecomes: 



ji 



= fj.52/(l4l + ui^C^fRsHv)) . 



where oj ^ 27ir. Cj isjuuclion capacilauc(;\ I^ is diode satura- 
tion vurientH lis is the series resistance, and By is the junction 
resistance. 

Load ResistanCB. The diode resistance Rv at zero tjias is lisu- 
ally not small compaied to the load resistance lli. If the 
diode is considered as a voltage source with impedance Hy 
feeding the Load resistance R^^, the voltage sensitivity will be 
reduced by the factor Rl/(Hl + l^vJ? *^i*^ 

7- - Vt(KL/(Rv+ Rij) . 

For example, a ty]Dical load resistance is 100 k£L If Hy is 
5 kfl then 

Reflection Loss. Further reduction in voltage sensitHlty Is 
causeti by reflect iou losses in the rnatching circuit in w^hich 
tile diode is used, lu Fig. X tlie package capacitance C|,]^j, 
and jjackage induct ance L^ug can be used to detennme the 
pack age fl diode reflection coefficient. If this diode tcrini- 
nates a 50 Q system, tiie reflecUon coefficient p is: 

p = (Zd - 50)/(Zd + 50) , 

where Zy is a func^tion of frequency and the package parasit- 
ics. If there is no matching network, the voltage sensiti\4ty 
can be calculated as: 

Yil = 72(1 - P^) ' 

The chill, package, fuid circuit parameters all combiiie to 
defiue au optinmm voltage senshivity for a given applica- 
fion. Our design goal was to develop a tUode to operate in 
the fre<juency raiige used In RF;1D tags. Using the voltage 
sensitivity analysis described aliove, we hojied to jModuce 
an n|)timum, low-cost, manufacturable pait in the shortest 
tune ];iossible. 

Implementation and Fabrication 

H e \\ h'U - Pac karc Is p r e e i ni i \er\ t z e r ( y bias detector diode 
(HSC'H-'W86) alrt^ady j)ro\ides excellent detection sensitiv- 
ity in an axially leaded ghiss package, paiticuimly at liigh 
frequencies. To meet oiu" design goals, the project team 
decided to leverage the HSCH-i486 technology. 

We chose the plastic SOT-23 package liecause of its low 
nianufactming costs for high-votuuie products. Using the 
S()T-23 package, several mochfications were possible tliat 
we hoped vi e could take advantage of. Before building 
prototyi^e devices, we made a detmied device model foi' the 
HSCH-f^Stx Tl\e nu>dei lieipeci us fabricate an optimum de- 
vice with miniinuni design iterations. 
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Two-dimensional process and de\ice simiiJators were used 
lo mmki and predici the performance of the HSCH-3486. 
Diode pammeters such as silicon doping, area, epitaxial 
layer thickness, metal pad size, and passivation iJiickness 
were included lo study the efTetls tliat iJiese process parain- 
eters had on diotie electrical performance and ultimately on 
detector performance. A tjpical sensitivity' analysis (Fig. 4} 
showed the effect of contact area and epitaxial thickness on 
voltage sensiti\it>^ 7^1, assuming an ideal matching circiiir. 
The niodel was aiso used to check for ^sensitivity to parame- 
ters that are not directly measiiral>le during |>rocessing, such 
as surfece states ajid recombj nation vek^cities. Tlie model 
was good for trend analysis but could not be used to predict 
absolute values unrii devices were fabricated and tested. 

Using the vanotis e<| nations for voltage sensitivity, it is com- 
n;on to plot -fj^ as a fmiction of the saturation current 1*^. as 
shown in Fig. 5, for given values of Cj, R^, and Rl. Since Cj> 
Rg, Rvr and I^ interact with one another, it is not simple to 
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Increasing EpiiaxJsl Layer Thickness fO.2 ^^t/div} 
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Pig, 4. HlffW'ts firepitaxuil layer iluckm^ssaiul run! aci area on 
vifliiige sensitivity, f = 5.8 tJHz. Hl = HfO IcO, 
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Fig* 5. VVtitage sen.sitivity as a function of satumtion cnrrt^nt. 

lower Cj, say. witlioui inereasirtg R^. By using the model, w^e 
were aljle to select the best conilnnatioii of these pai'ajne- 
ters to n>aximize the voJtage seiLsithliy at a given freciuency. 
The process m* Kiel ensured thar our design w^as within Uie 
limits of our existing manulartmlng capabilitj^ hi tlus way, 
w^e were able to minimize development costs ajid time to 
market. 

The fabrication process is relatively simple. Using a heavily 
doped silicon wafer siibsti'ate (to keep R^ low), an epitaxial 
layer is grow^i witli tight controls on tlie doping tevel, tluck- 
ness, and doping transition wldtli. After silicon dioxide and 
nitride passi^'ation, photolithography is used to define a con- 
tact window, A well-controlkxi metal process is used to de- 
posit I he metal which defines ni<iiiy of fhe criiicd paranie- 
ters. Tlie tnetaJ is eti iieti 10 an appropriate size for l)onding 
in the plastic package. The wafer is cut into individual die 
and attached to a leadft^ame using a silver ppox>'. It is then 
molded into the final plasti<' configuration. Fig. 6 show^s the 
device cross section and die layout. 
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Fig. 6. (a) HJiMS'285a dJoiir f:ros*^ si^rtion. {t>.) Ui^ lay out . 
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iiH tH iiH ir^ 10-* 

Saturation Current + Bias Cyrreni {A] 

Fig, 7* CaltHilateti vfiJtage sf iislti\iLy for zero liias S<hnttk\' 
dicj{|i?s ha\irig R^ = 650 aiid Cj - 1) J5 pF. Rj, = lOU kQ . Dots 
shi>w niy^ured values far 930 MHz, 2.45 CJHz, a] id ^.8 GHz. 

The packaged tie vice can be 100% tc^isted for various dc pa- 
rameters such as fbiTrard voltage bias Vj and hreakdowii 
voltage Vfjr, Mairy of the dv parameters havc^ been conelated 
wit 1 1 higfi-rreijueiiey paranteters, thus eiisurmg the perfor- 
maiue of each part and eliiiiinaliiTg the high costs associated 
with ]iigh-frequei\cy tests. 

Performance 

The itiitial lots tiiat were processed after l>euig designed Ln 
the process atid device sirrvnlatt>r peifontted very closely to 
the i)redicTpd values. Minhiid intJiiel changes were iK^ces- 
saiy. In fact, the results were sufficiently good tliat no 
design iterations were necessary and the data sheet Sfjeci Il- 
eal ions were set using those lotB. Although we did not expe- 
lientre the normal kinds of pi'ocess vaiiation that we would 
expert over a lotig peiioil of time, oiu' ronfidence in the 
model accuracy allf)we<l us to sitntilate these vaiialions to 
show that tlie spet iOcation would still be met. In acUhtion, 
we could use the model to determine what process and de- 
vice parameters could be changed fra^ fiUure im[:aovernenis 
to the diode. 
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Fig. 9. s Vinipan.son of tvvc? ^ero bum Srhottky diodes. 

Figs. 7 and S shtiw actual voltage sensitivity contpared to the 
ctdculated values. 

For comparison with the HSCH-^3486 glass package diode. 
Fig. 9 shows y^ as a fi mention of frequency. The rlifferent \al- 
ues of Cj, R;^, and 1^ of the two diodes cause the HSMS'*285(I 
to provide greater performance at frequencies less tiian 3 
GHz while tJie lISCn-3 486 is supeiior above 3 GHz. Because 
of its simpler i>ackaging and testing, the HSMS-2850 is much 
lower- in cost than tiie HSCH4i4S6, 

Cone his! on 

Hewlett-Packard's newest silicon zero bias detector diode 
has one of the best piice/perfomiance ratios on the market. 
We feel thai these diodes will become an integial part of 
many tag applications being designetl totlay and will be con- 
sidered ui future designs ami techiu)lr>gy. They provide ex- 
cellent voltage sensitivity for many of the freriuency ranges 
being used in the RF/ID industty ai a very low cost, 
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loining HP, fie worked at ATST Bell Labs developing 
voice trar>S3crion systems and at SyneSort Jric devel- 
oping file restmdufing saftware for index files He is 
married 

Lawrence J. Rose 

Larry Rase joined Apollo 
Computer the year ii was 
acquired by HP and is now a 
softy^'Bre engineer wrth the 
Open SystBms Software 
D\\'i%m He work&d m IBM 
ernulatson products and ioie- 
grated: SMA, He lias contrib- 
uted to the developnient of 
DCE admmistratian tools and is currently working on 
OpnView inligration Before ApoElo, he was a soft- 
ware engineer at Adage, loc. and at Wang Laboraio- 
ries. Inc. Larry was barn in Norwood. Massachusetts. 
He is married, has one child and one onthe v^y. arvd 
is a Little League coach m Chelmsford. 
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Frederic Gittler 

Born \n Antwerp. Belgium, 
Freddie Gittfer grarluated 
from the Ecote Nationale de 
la Siatistiqde et de TArimi- 
nrslraiion EconnrriJciuB in 
19a4antjfTDmthBEGoie 
Natl Rale Super leure des 
Telecosmnunications in 
1985 Both jns|itutior>s are m 
Piiris, i-rance f redGnc had a dream of working at HP 
since he was sixteer), which he realized after gradu- 
atmg from [jollege. In 19B6 he joined tiie HP Colorado 
Networks Division, whera he developed software for 
K,25 and v^ id e- area networks He transferred to The 
Che?msford systems software lah in 1990. where he 
managed networking and distnbuied camputing proj- 
ects for four years. He is currently a senior engineer 
in the Open Systems Software Division and is work- 
ing on distributed security products. Frederic fs mar- 
ried and has two hoys. He spent one year in the 
FrerKh Navy as a Reserve Officer. He j? mterestad in 
the arts and traveling and enjoys accompanying has 
wife in her outdoor activities. Frederrc also has a pas 
sion for automobiles and high-tech gadgets 

Anne C. Hopkins 

.Anne Hopkins came to HP's 
Open Systems Sottware 
Dfvtsion when Apollo C 
iiutef was acqojred in iv _ 
■ ; -- has worked on the De- 
:. yn and deveSopn^eni of 
DCE security services for the 
past SIX years, inciudtng a 
».-..---—*= :, brief interlude as the techni- 

cal proisct Eead ror the HP DCE 9000 1,1 release She 
IS cun-ently workmg on the HP COHBA security speci- 
fication and is HP's technical representative to the 
Ohjed Management Group regarding seconty Before 
coming to HP Anne worked at Wang Laboratories. 





Inc develoning OSI network software and at Imagh 
Tek developing electronic prepress publishmg sofi- 
ware. She is a member of the IEEE Anne was 
awarded a BA degree from Dartmouth College m 
19&5. where she majored in computer science. 
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Detiorah L Caswell 

a A system archjtect wnrktng 

atHPLatJoratoriesforthe 
second time m her history at 
HR Debbie Caswell IS cur^ 
k xr^ A f entl y t esppnsi bl e far the 

^^ftii-rf*^^^ future server architecture 
^M ^H providing residential broad' 
^^^^^^^^^^k ^3^'^^ services She joined HP 
^^^^^^^^^* in 19B1 and worked as a 
quality assurance engineer at the Commemial Systems 
Division She then c-onrdinated the HP softvi^are met- 
rics prngram at Cnrporate Engineering After complai- 
ing her masters degree at Stanford, she jocned HP 
Laboratories for the first time and worked on the X 
WinrJow System ard vanous di.'itribuied system tech- 
nology, She then led the effort at the Open Systems 
Software Division to productize DCE on the HP-UX 
pfatform befare the project was moved to the 
Chelmsford system software lab, She wrote this HP 
Journal article while working for the Network Sys- 
tems Architecture group wliere she codeveloped the 
DCF programmirig examples that are shipped witfi 
HP's DCE product and was a memher of the HP 
DO DCE design and prototyping team She is profes- 
sionally interested m distrihuied computing and is a 
memher of the IEEE She has coauthored a book pub- 
lished by Prentice Hall on software metrics. She 
earned a BA degree at Dartmouth College in 1981 
and an MS degree in computer science at Stanford 
University in ISfiB. She was a summer intern at Bell 
Laboratories m Murray Hill and worked on the osef 
interface for GetSet Ian integrated terrtiinat and tele- 
phone I Barn in Summit, New Jersey, Debhie is mar- 
ried and h interested rn vcdeography and home im- 
provements She also enjoys singing, cross.country 
skung, and snorkehng. 

B HP DODGE 



MiliaelaC. Gtttler 

Burn rn Romams. Mickey 
^1^^^ Gittler earned a Diploma of 

^^^^^^^ Electrical Engineering in 

^B ' I^H J Institute of lasi In 1 984, she 
m -^^ ^Bm '^^'^^'^^^^ 1''^'' masters de- 
^^L -r "^^^m 'jree in computer scienrr- 
^^^^^^^K Uie Culorada Stale Un:v^i- 
^^^^^^^^^^ sity m Colorado. She loined 
the Desktop Computer Division in 1978 and is now 
working at the Open Systems Software Division. In 
her carear at HP she has developed softvvarB for data 
computer products., lem-iinal emulators, HP propria 
etary open systems InetworksL and network applica- 
tions She is professionally interested m distnbuted 
computing and obfect- oriented design and has 
worked on distribirted systems at HP includir^g HP 
OOOCE. which is her current project She designed 
and implemented the HP OODCE registry classes and 
helped to make the HP OODCE pr ■- 




She continues to enfiance HP OODCE and to do Train- 
ing and consulting with employees and customers for 
the product, Mickey is married and has two boys. She 
likes outdoor activities such as tennis, cross country 
skiing, and backpacking. She is interested in the arts, 
travehng, and eight-hngered Norwegian trolls who 
like chQcolate 

Mfchaet Zhijing Liro 

Michael Luu is a .suflware 
diigineer in the Chelmsford 
systems software lab at HP's 
Open Systems Softv,/are 
Divisinn He completed a BS 
degree m physics in 1987 at 
the Zhongshan University in 
Guangzhou, China and an 
MS degree m computer sci- 
ence in 199Q at the University of Massachusetts. 
After graduating, he iflined HP and has worked an the 
development of OSF/V DCE. and HP OODCE He is 
currently developing cfOss-plattormclient./server 
development tools for MicrossofL Windows '^' and 
HP-UX*. 

iujs M. h/laldonado III 

Luis M Maldonado 111 gradu- 
ated from the Massachu- 
setts Institute of Technology 
in 199Z witha BS degree in 
computer science and engi- 
neenng. He is professionally 
interested in distributed sys^ 
terns. While in sr:hoDl he 
[:ampleted an internship at 
Digital Equipmerd Corporation which involved the 
development of distributed applications After gradu- 
ating, he jomed tire CheUnsfcrd system software lab 
at HP's Open Systems Sofh^are Division He has 
worlted an DCE application development tools, DCE 
IDL, DCE RFC. and the iiJ?t+ compiler He is currently a 
DCE R PC engir^eer, Born in New York. New York, Lms 
IS an automobile enihustast and enjoys sports such 
as snowboard ing, mountain biking, fencing, and vol- 
levball 
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Pankaj Gupta 

^^^^ A software en gi nee r at t h e 

^^^^^^ General Systems Division 

m ^ since l9BB.Pankai Gupta 

^' ' ^ contributed to MPE/XL 

transaction management, 
MPE,/XLonlme backup, HP 
Encina.^'KL. and HP Encina/ 
9000. He represents HP at 
the X/Dpen * transaction 
processing working group. Pankaj earned a BS de- 
gree in electrical engineering in 1981 from the Punjab 
University in India Fie completed hrs PhO in computer 
science in 1988 at the State Umversay of New York 
in Stony Brook, 




>i^ 



t(Hl 



I JtTi^jTiin'r li-Jtf.i Hewli^rr-Pai^kajTl Joiiriiii 



)Copr. 1949-1998 Hewlett-Packard Co. 



75 Obfea-Onemed Teslmg 



Melaflaiiii 



f^TciiS Cafn(^lt was : 



W 

^Bk^^^^^^^ pJetmg his BS decree in 
^^P^*^^^H compiiter science 3? Bostun 
^^^ ^^^^ Unti^sity He joined HPs 
Open Syslcfns Software Oivssion in 1SB9 \vtien 
Apollo Computer was acquired by HP. As 3 saftware 
design ef^gmeen hrs coniribations intluiJe testmg 
work on DCE. software test development for HP 
CORBA projects, and designing ttie ob|ect lesimg 
frame work More recently he has worked on HP ORB 
Pius and is currerrtly doing development on the latest 
version of thfs product Before coming to HR he 
worked at LoiDb Software nnaintaioing busme^s appli- 
cations for hospital reimbtirsements Marcos is 
man-ied and has five children. His hobbiet include 
swimmmg. fishing, and boating, 

David K. Himls 

A saftware engineer Jn the 
nisford systems soft- 
:.^t;ab at the Open Sys- 
tems Software Division, 
□avid Hinds came to HP in 
1983 V^hen Apollo Computer 
was acquired. He has been a 
reliabilityengmeer for 
Apo i 1 workslat 1 ns a nd a 
software engmeer responsible for testing DCE and 
the OSF/1 operating system. He is also responsible 
for the design and implementation of system testing 
for HP CORBA, He IS a member oJ tbe IEEE and is pro- 
fessiDnallv interested in software testing. Osvid 
graduated with a BS degree in electrical engineenng 
frpm Northeastern University. He is married, has two 
cbifdren, and enjoys skung and sailmg. 

Ana V Kapetanakis 

Born in Boston, Massachu- 
^^1^^ setts.AngKapetanakiswas 

^^■^9^ a weeded a BS degrea m 
^^FW^^ electrical engFoeenng at the 
^m^ "^iM Worcester Polytechnic Instt- 
^H |h Lute in tg^l and an MS deh 

^^Kl y^^k 9>'^^ ^^ computer science at 
^H^^-j^^^^B Boston U n 1 ve rsity 1 n 1 995. 
^^^^^^^ She joined the Open Sys- 
tems SoftW'are Division in 1392 as a software design 
engineer She has worked on DCE lestmg, HP ORB 
Plus testmg, and the obieci testing framework 
design. She is currently participating in the develop' 
mem of HP ORB Plus, Ana i^ married and enjoys golf 
and sailing 





J. Scott Soifthwoflfa 




^ ng HFs Open Systems 
•v^re DivtsEon in 1^ 

sfid 



a system test 
arigir^es:, a software inte- 
graiioner;^ - : a hardwafe support engineer 
Before worlting at Apollo Compmer, he was a hard- 
ware systems engir^eer at ComputervisfOn Steve was 
awarded a BS degree m electrical er^meermg m 
1SB4 from Northeastern Universitv- Born in Everett. 
Massachusetts, be is married and his hobbies irKlude 
wood car\^ng and gardenmg. 

Davtd S. Levin 

David Levin was bom in Phi I- 

' leiphia. Pennsylvania. He 
■ :'ed the Chelmsford sys- 
'. -=5 software tab at HP's 
' ?. en Systems Software 

PV Jf - ■ ■ siori m 1 989 when HP 

' >— / ■:: L:uired Apallo Computer. 

While at Apollo he was tbe 
manager of software inie- 
grabon, and before Apo! Co he worked at Software 
Arts and HonsyweH's Cambridge Information Systems 
lab. He is currently the technical lead at HP for the 
distributed computing systems testing team He pre- 
viously worked on systems test and the development 
of a CORBA interface repository for one of the HP 
COBBA projects. David graduated with a BA degree 
in philosopby from Clark University in 1972. He is a 
member of ACM. He is manned and has two sons. His 
hobbies ui elude bicycle commuting, woodworking, 
and skhng 

David J. Miller 

^^^^^^■|H| Dave M 1 er j ai rred H P's 
^K^^^^^^^ '"^n'^n Systems Software 
■HT X vision in 1 989 after HP 

■■^ ^Jk .: i.;jired Apollo Computer 

ip! W ■'■■ 1^ currently working an 

"'ware system tesimg for 
• ■■ibuted computing prod- 
ucts He has contributed to 
the devefopment and testmg 
rii MP uHb hus anil contributed to the design ard 
implementation of HP's OMG compliant event object 
service Before coming to HP. he was the manager oF 
graphfcs hardware at Apollo and workstation proces- 
sor development at Compuiervision He earned a 
BSEE in 1971 and an MSEE in 1975 at Northeastern 
University in Boston, He is a member of the IEEE 
Born in Haileton, Pennsylvania, Dave served in the 
Massachusetts National Guard. He is married and 
has two sons. His hobbies include gardening and 
figuring out crossword puzzles. 
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Scott SoutfTvyorth i<jined 
n ISSwfien Aoollo 



: 2 earning 
H. tye i% cur* 

:^-JtJ^ tai^ZT-^itm for the 
. r distributed object saftware 

His ^rt'vjQui c^.^i;:ji;^:3ons at HP have mclyded i^»- 
nical writing tor distributed object software, compiler 
Jmking. and RISC fegrsier usage He has also devel- 
oped online help systems, coded text analysis and 
jfmIb* analysis software tools, arid created a master 
indeK f^r 175 documents J Scott was awarded a BS 
degree in urban studies from the Massachusetts 
Institute of TEchnplogv <n 1372 and an MA degret in 
counseling from Beacon College m 1979 He worfted 
as a technical writer at Digital Equipment Corpora- 
tion and Apollo Computer before coming to HP. He is 
a member of the IEEE, ttie Boston Computer Society, 
and the Society for Technical Communication, Pfofes- 
sionally interested in online help systems and text 
analysis tools, he has published five technical ar- 
tfcles spanning distributed object computing, hyper- 
teKt. and indexes. He has also written a book about 
high-tech careecs. J Scott ts married, has tvra chil- 
dren, and BOjoys jazz and science ftction writing. 

82 HP 50 T Fetal Telemetry System 

Andreas Boos 

^^^^^■^^H A n dreas BoosisanBSiO 
Hj^^^fQJ^H ^.'ngineer at the Pabent Mon- 
^^B^^^l^^ imring Division As a techno 
■ ^ ^M :< project fead. be has been 

T' T ^ ■:spansible for the engineer- 

* •*• ■ J of total monitoring sys- 

itrnis, especially signal pro- 
cessing hardware and 
software and the support of 
clinical trials. He is also responsible for ASIC devel- 
opment and project documentation His work has 
produced two patents involving tho enhancement of 
ultrasound signal processing and the operation of 
medical equipment using bar codes. Andreas was 
born m Zwalbach, Germany, Ho was awarded a Di- 
plorn Ingemeur in electronics In 1985 by the Univer- 
sity of Kaiserslsutern Upon graduating, he joined the 
HP Bdbfingen Medical Division Andreas is married, 
has two children, enjoys listening to all bnds mustc 
from classical to pops, and likes to play volleyball. 
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Mrchelle HoughtDn Jagger 

Mjc^elEe Ja§gfir is a mafkei- 
irvg communlcsUons specia' 
ist at the Patient Monitoring 
Division, Siie is respnnsJble 
tnr worldwide nnarketing 
, 1 MM m cammunicamns for obstetri- 

f ^J i ca? and neonatal products 

withintliBMedicalPfoducts 
Group She carne lo HP in 
1992, |Ginmg the Bbblingen Medicai DJvasion. As a 
iearnmg prorlurts Rrygrneec she was respcnsJbJe for 
the technical documentatfon for fetal monitDrs and 
telemetrv Then as a marketing Gommumcations spe- 
cialist she was responsible fo^ the product position- 
ing and launch of the HP Series 50 T and of HP Series 
50 OBTraceVue Bom in Bristol, England. Michelle 
has a BA degree in modern languages and informa- 
tion systems. She is a member nf the British Com- 
puter Society. She participates m sports of all kinds, 
especially sJ^nng and tennis. Traveling is also a favor- 
ite because she er\joys learning different ianguages 
and being B5<posed lo different cultures. 

GunterW. Paret 

Giinter Paret i^ the project 
manager for feia! monitoring 
REiD at the Patient Monitor- 
ing Division and managed 
the development of the 
Senes 50 T fetal telemetry 
system. Previously, he 
worked on the development 
of the hardware, software, 
and servtce support tools for the HP 6D4DA and HP 
8041 A fetal monitors and was the profect lead for the 
deveJopmentof the HP M135QA, HP Ml 351 A, and HP 
M1353A fetal monitors. He is named as an inventor 
in two patents involving an algonthm that detects 
coinctdences in heart rates from different transducers 
and a service tool thai activates circuits of electronic 
devices for program modification G (inter iotned the 
Bdblmgen Medical Divisjon in 198D after earnmg sn 
electrical engineering degree from the University of 
Stuttgart. He was born in Santiago.. Chile, is married, 
and has two children He enioys playing music on the 
electronic organ, is interested in video techniques, 
and loves "to go awandering'' in the Black Forest and 
the Aips. 





Jurgen W. Hausmartn 

A technical marketing engi- 
neer at the Patient Monitor- 
ing Division, Jijrgen Haus- 
mann provides technical 
support and strategies for 
fetal monitors and fetal te- 
lemetry systems. He was 
bom in Neuhausen, Ger- 
many and was awarded a 
Drplom Ingenieur in electronics from the Universitv of 
Stuttgart in 1 9B2. He joined HP at the BiibJingen 
Medfcal Division in 1982 Jurgen is married and has 
two children He enjoys outdoor sports such as saii- 
mg on Lake Constance, skiing, and hiking He also 
spends hES free timt designing elactronic circuits to 
automate his house. 
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Rolando H.Buted 

Born in HonoloJu. HawaiL 
Rolando Buted earned a 
BSEE degree at the Univer- 
sity of Hawaii in ISBI, After 
graduating he joined HP's 
Microwave Semiconductor 
Division and is now a mem- 
ber of the technical staff at 
Me Communicatjons Compo- 
Lull ling to HP. he has worked as 
an R&D engineer on product and technology develop- 
ment for discrete and IC compDnenls for wireless 
Gornmunications. and as a manufacturing engineer 
responsible for yield enhancement and product end 
process improvements for discrete diodes, He waii 
the project leader for development of the HSMS'2850 
Series diodas and vvas responsible for the product's 
release to manufacturing. He is currendy responsible 
for developing an improved detector diode. He is afso 
working on a high-frequency p-i-n diode switch and 
on a tec boo logy fihrar^' expansion for the I SOS AT 
process Lfsed for IC components, Rolando is active in 
the East Side Academics Mentor program and volun- 
teers in the Newark Unified School District science 
programs. He enjoys outdoor activities such as vol- 
leyball, golf, and skiing, 




HP-UX 9.* and 1 D.O for HP 90DO Ssrles 700 ami SOD ccmput- 
EfS are X/Open Company UNIX 33 branded praducts. 

X/Open is a registered trademark god the X device is a trade- 
mark of X/Opert Company Limited in the UK and other coun- ■ 
triei 

Windows is a U.S regisiered tradamark of Microsoft Corpo- 
ratjon. 
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February 1J>95 

Broad baii(J Kroqiit'iu-y Characterization of f )ptk'al Rpceivers Using 
Intensitj' Solst^.DoagifJs M, Bata'f/ami Watfm' V. Sunn 

L55-itni Fiber-Optic AmpliHer 

Erbium-Doped Filler Amplifier T€^ %siem, Edgnr hrfcel, Jiirgen 
Sang. RolfMiiHrii Ck'7iiett,'i Ruck, tifid Chnstiaft Hcntsck^ 

Miiiti-QiianHiin-Well Ridge Wavegoide Lasers lor Tiinable Exlemal- 
Ca\'iry Sources, T^ntmah R. Ranganalh, Mivh^fct J. Lmlowise, 
Patiififi A. Bet'k\ Df*ftiiisJ, DcnrksatK Wilt htm H. Fny^z, Jim L 
Bijtlit^li^ find DiiVid M. Bintm 

Mfasiirenieni of Pulariz-iir ion-Mode Dr.sjH^i'siiJri. Hnnn L Hfiffn^r 
fttid Paid R. Ilentdtti/ 

Jnrios Talc til us 

'rite Pohicarc Sphere 

T\w HP 8*W>A/B Liglitwave Polarization Analyser 

A New Drainii ApiJroach for a Progr;uninal>le Opriciil Al tenuator, 
Sietpwi r Sfiimidf ami UulmQ Finfiar 

Preciskm Rfneiiouieier with Spiirioufj-Free Knliaitcwl Sensitivity, 
Dfti'id M. ihrtitti. DttinisJ, [knirkMrn, t^uiaM. Fernmidf'z, tmd 
<ti eg tX L r{ 'h rm i tf fi v f 

Higli-Pejwer, Um-Inlemal-ReOeciton, Edge Flmitting Li|;bt Eniilting 
XyuMh'^Jk'KHis tL fk'ritksfm, Palrtew A. liffk, Tim L fiarjwdi, 
ihivhl hf. lit ft if tt, Jiifit' /'.', Pfiitqiit^f, Fonrsi G. KrUt^rt, MirhadJ. 
Liidfiwise, Willhtm IL PfTf^z, Tirtimaht R. Riuupumtlu (iotyR 
7)rttf, ami Stisatf R. Slotrti 

Jitter Analysis of Higl^-Speed Digital Systems, Christopher M Mdh*r 
find Damdd. MrQmiff 

A Lit OH union of t>|.>tiefit T^me-Dtjmaiii ReHectometry Measuremems, 
Frank A Mmcmmi Humid St*egtrf' 

Design mid Perfon nance of a Narr*>wband VCO at !I82 Tl Iz, 
l\'ter R. Roiirish. CtirLstoptirrd. Xhdiien, Rmy L. \rinTu_ift, ami 
Witiiam R. lyahta, dr 

Siiiface Emitting i_*asej' for xMultinifKie Dati^ Link Ap|>ljraii[ins, 
Mickafd RS. Tan^ Kenmfh H. il&fin, Ytt-Mhi D. Homuj, find 
Sh Ith Yumi Wa ng 

neneratiiijiSJifiri.- Wavelength iJgiit Ising a Verli^'al-C'avity Laser 

Slmvi\ir&, Shigeru NakagawfL DfUftri^ E, Mtirfi. find Nfrri hide 

Vfimiida 

A New, Flexjbie Se<|uencer Architecture for Testing Complex Serial 

Bll Streatns, Ruhni K. Mt'Anit(ft\ dfun*'^ L. Bcnsfm. find (Iwislophi^r 

a fa hi 

Hhoneninj^ the Tinve to Vokime Pn Kind ion of lligii-iVrrorrnaiK e 

f^imulartli^li AiilCiij'hjtf II MrDougal timf Widittm E. Votifitf 

A Frainewurk for Iriisight into the hnpaet oflnterioniTecl on 
O.^iG-inin VLSI Pi illomiance, l^msad Fkye 



Synthesis of l(Kfh\ Delay FatiU Tesiairfe Comhinationai C'irruits by 
C"ut>e ParlitJotxitig, Wdtittm K. Utfu 

Better Models or BetU?r Algoritlui^s? Te< luiiyijeii in Improve Fault 
Diagnf>sis, Rohert C. Aitkmt and Peter C, Miu^VPii 

Bridging ami Sttifk-At Fatilis 

Pole J 11 ial iJet eet ion ' 

April lf)95 

A Uiw-t.osl, High-!¥rfon!>iitKe PA-RISC Workstation \^ith Built-^hi 
Graphk'is Muilimetlia. and Networking Capabihtles, Roger A, 
PearHtm 

Tlie PA 7100LC Microprocessor: A Case Study of IC Desigti Deci- 
sions in a Competitive FInvirfuunent, Mitk Rass, Ptifnrk Knf^fieL 
Damd W. Qiiinf, ttnd WHtifim L. Wtdkt^r 

D^ign Methodt)logies far the PA TIOOLC Microprot^essor, Mick 
Bu^s, Ti'rrg W. Btfinchtti'^L D. Dfjughis dfinf^phntm, Duman Weir, 
ami Dattict L Hid peri n 

All I/O System on ii Chip. ThomuH \{ Sptrntcn Frank J. Lcttfintf, 
CurtLs R, MrAtli.slcr, An than a L Hierio, Joseidf F Orth. and 
Brian K. Anio/f/ 

An InlejirJited rirapllic -■> A< releraTor fi»r :i l^iW"(-ost Multimedia 
Work^lat i t m* f V/ it i Ma 1 1 i u 

HP ('olor Recovery Tbc?hnoloj^, Anthony ( '. Barkaas 

lYue Ctilor 

ReaUnme Koftwait* MPEti Video Deiroilei on Mnllinu dia-Errhiinee<l 
PA TIOOLC F'roeessorH, Rui/i/ B. Lf't\ Jahv P B('ck, Joal Lamb, and 
Kennf^tit E, S<Tf't\son 

OvTr\1ew of the fniplemenlatkin of tin* PA TUUJiC MuJUmedia 

Enhancement 

HP TeieShan- Integral ing Telephone CapahiHt^es on a Comptltj^r 

Workstation. .Sv Pfud Titckfr 

CaMer-ID 

(^iill Progress, DTMF Tunes, ;iiid Tone Derer! ion 

Product Design of the Model Til Works Uilitiri imd Exfernai 
Peripherals. /tr/p^^ L Roesntfr 

Develt>pin(^nt of a Low-Cost, High-Perfomiance, Multiuser BiLsini?ss 
Serv'er System, DninlsA. Bonfts. finftrilM Enkfiiitt. anti Kat'in 
L. Mnnfhi 

HP llistribttti'd SniiiiltidJc: A Tool for Devclutung Distributed 
Appbratjons, Eitmn KrjTmitsi.*i ami Ittn J. Ftdlrr 

t)l>ject MiUtiigenient fironj) 

ASc*fl.w*ire Solution Broker for Techniial Consul tajits. Mdnng 
Ytmsefl, Add (ihomdrng^ ami Wuif Rfiafrr 

IIP S(jft wan- Sohilicju Broker Accessible ProthK ts 
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Bugs in Blat'k ami Wliitt*: Imagutg IV Uigic Ijeveis with Voltage 

Coin pan pni and S.Viiiieni Ijevel Design-for-Ti^sltthilily Fea lures 
Implpnicnteii in a Family cjf WoikstaliDii PrtHJiicts, Bnlmit /. 
Denmogh find MUhuji Rkchetii 

June 19!>5 

Capillaiy Elet troijhrjresis: A Pi fjtiufj tjl' Tet hivolftgifid Fusion, 
Robert R. HoUouuij 

A New liigi^PerJbmiaiue Capilliii^ Electrophoresis Instninienl, 
Fred ShGhmeier 

t apiilary Electrophoresis Applications 

IIP CE TGclmolog>^ lYansfer 

fndustriai Design of the IIP C'E IiisLruj:Lient 

A 1 !igh-SeiisiTi\ity DkKJe Array Defeeroi' f<;)r Ori-Columii Detection in 
t 'apillaiy ElectrophoresLs, Pairlck Kattmhai'h 

(;apiliaiy Hanilling in the HP Capillary Eletirojihoresis Itistrnnienl, 
hi/ Uniis-Peter Zlmmf^rmittiH 

Rapid Proloiyping for \]w HP CE Pnijed 

Sample Ir;iection in HP C'E. WenwrS^^huelder 

HP CE Separalion Control Electronics and Firmware, FhU Bf^k, 
Fntnz Bi'^tlsch^ and Klau^s WiU 

A User Interface for CapiLlaiy ElectJtjpiiojesis, Alain Rif^^rudnn 
Hfidmmis Win 

DevelopriH^nt of a C-onirnon CliemSlalion Aivhilect.ure 

Reisrockicihility Testing f>f Ihe HP CE Instrument, Utrikp Jegle 

TJie hnpacl of Cohunn Tecluioiogy on Protein Analysis by Capillary 
EliHiroplumyis: Sm Huf ( oalinjdjs aiu] Aiisilyric al A|n>n>ac'hf^s for 
Ajssessincuit, SaUij A. SiVifdhpiy und MoifU^tt Dithtianfi 

A New Hjgh-Sen&ili\ity Capillary Electrophoresis Detector Cell atici 
A<lva:K'ed Man nfactn ring Paradigm, Giuyj B. f]fndfHK Rirhanl H 
IWrt . ai fd I {frfi i fq a r . L S. Mo rf in s 

HP Disk j\rray] Mtiss Storage Fault Tolerance for PC Servers, Ihm 
A. Skele and Mix had R. Rusnark. 

An Overview of Haid Technology 

COBOL Softlientli: Ai\ ( Ijien hitegrated CASE Emironmeiit, Chenji 
Cannithaef 

Development and Use of Electronic Schematic Capture In Llie 
Specification and Slniulaiion of a Slruclured-Custoni ASIC, Drjrid A. 
Bmyoon 

Design iind Development of a l^O-MHsc Bus Into if ace Block Using 
SlantlanJ CeMs and Autoniatic Plact^ and Route Tools, Robert E, 
Ryan 

August 1995 

Introduction to PinV(r-AnyU\N" and ihe IEEE m2Al Lot al Area 
Network Htandarct Alan R. Albrtriif atnf Rtftrft'fft A. Tinder 

Cable IVfies 

Other Network Technologies 

Demand Priority Protocol, At<\n R, Alhreeht, Mhiiaef R SitraH, 
Patricia A. Tlniier, and Gregonj C.A. Wtitson 

Network Protocol Layers 

Physical Signaling Lu lW\'Q-Aj\yLi\.H, AUstfilr N, Co^es, Dmnd O. 
Cutiningharn^ JfjsephA. Cmvio, Jr.^ Daniel J. Dqi% and Steven G. 
Methie^ 

Cross Talk m l^nshiekled Ti\isted-Piiir Gables 

Mill tile vei Signaling 

Cross T^k Analysis 

Optif ai-Fiber Unks for lOOVG-AnyLAN 



C'Odirtgin iOOVfj-Anyl-AN, AVwo/^ EX\ Cmttfh and douatknn 
Ji'dit'fth 

fEEE m2,S and 802.5 Frame Fonnats 
Polynomial Aritlimetic aiid Cyclic Redundancy t -hecks 
Mnltiiiur'dia Applications mul lOOVG-AnyLAN, Jf^i/r^; /?, Griidntm 
and MicitaelP Spnilt 

Remote Bridge Example 

Higher-Level Protocols 

Related Project^^ 

in0VG-.AiiyL\N 15-Pojt Hub Ues'm, Urn S. Bnmm 

Invalid Packet Marker 

IIP AccuPage 2.0: A Toolkit for High-Quality DcKninienl Scanning. 
Steven L. Webb. Steven G Heto% Kfrin S. Burke, and (r forge 
Pmkop 

An 1 l.S-in Flat Panel Display Monitor. DaMd J, Hodge. Brndh/ J. 
Foiffer. Stenvn J. Kfnnmnisch, urtd Tafu J. SeaHiy 

Liquid Crystal LJispIay Technology 

Product Design of the HP SlOlOA Flat Panel Display 

A Note About VR.'VMs 

Applying an Improved Economic Model to Softwrare Buy-versus- 
I3uild Decisions, Wrsley H. iligaki 

I3cntlimark Stanilaids for ASIC Technology E\^luation, Aulunlo A, 
Martinez, Moke S. Bkandia, and Henry H. W. Lie 

October 1995 

HP PE/^oUdDesigner: Dynamic Modeling forThree-Dinieiisitinal 
Computer- Aided Design< Klaus-Ruler Fahlbuacii and ThQmai> D. 
Roser 

User Interaction in HP PE/SolidDestgner, MerthM Hmj, Gerhanl 
J. Walz. and Mnrkus Kidd 

Enhimcemt nts in Blending Algorilhms, Stefan FrHtmj and Karslm 

OfjUz 

Open Datii Exctsatigc with HP PE/SolidDesignen Peter d. Schtld, 

Woifganff Kl^mm, (ie^rhard d. Wal^, and. Henna nn d. RuesK 

Proviciing CAD Objc<'t Management Senices throngli a Base Class 
Ubrary Vfanj^ Brod and Ma^r R. Knblin 

Exception Handling and IJevelopment Support 

FiTeforni Surface Moiieling, Mleliael Metzgerond Sabine Elsnumn 

Common Li.sj) as ati Embedded Extension Language, de}is Kilian 
and Heinz-Rel^* Arndt 

Boolean Sci (>(>erations with Sf>lid Models, Peier IL Ernst 

Flgliting Inaccuracies: Using Perturbation to Make Boolean 
Operations Robust 

A Mk rowave Receiver for Wide-Bandwidth Signals, Roberf d. 
Annan front 

Firmwaj't* Design for Wide-Bandw^dtli IF Support and Impn ived 
Measurement Speed 

The HP SMOO Series \ector Signal .\i\alyzers 

j\n IF Module for Wide- Bandwidth Signals, Robert J. Annanttrmt^ 
Teny^nceR. Noe, Chrisfopher E. Stewart, and Leonai^ M. Weber 

The IjOg Weighted Average for Measuring f*rinter Tliroughput, John 
J, Cassidy. dr. 

December 1995 

DCE: An Emiromiient for Secure Clieni/Sener Computing, Michael 
M. Kong 

Adopting DCE Technology for Developing Client/Server Apphca- 
tions. Paid Uoyd and Samuel !k fiomwitz 
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X/i)pe.n F<^«*ratc»d \ajjimg, Bli^ftbeth A^ Mart in 

HP Integral***! i*3igin. Jff II r B. MtnTtts, Sfii*atiep{ Kumar, nud 
Lawt^etwe J. Rof^f' 

TheDCE Spriiriiy S€»r\1c<*. Ftvdprir Gittter ami Amte C. Hopkitts 

All fo^oltrtkin ijf IK'E AultTr>riz:vtion Seniirt?*. Ik'ttomh L. CamveH 

All f->bjec"t4 JrieiitiHl Applicaiion Franiowork for DCE-Based 
Systems, Mihaiia C OUtlet\ Micfmei Z. Lun, und Liiia M. 
Mithkiniido 

HP Etifina/yOOO: MddJeware for ConstmctiiigTV'<in*sactio!i 
PrtKressifig Applications. PartkaJ Gupta 



Object-Oriented Pets|>eeti\Te on Softwan* System Tlrating in a 
Disftributed E«i1roimi€*m. Mafk C CampbeU. David K. Hinds^ Amj 
V Kfspftamikis, Ste^/fif^tt ./ AfrFatiand, David S. Lt^vin, David J, 
Milif^, and J. Scott South worik 

Tile rrtyect Management Groups Distributed Object M<jdd 

Objerr^riented Prograniniing 

A New, Ugjilweigbi Fetal Teienietr>" Syslenv Andrras Efms, Afiriivtk- 
Houghtait Jaggen Giinier W. Pan% and J&rgtm II! Hausmann 

Zero Bias Detertor Diodes fcir the RF/ID Market, Rolando R. Bnt^ 

E!aeksc:atter RF/lD Sj'stenK 
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lOBase-T lyAtig. 

lOOBas^-T KVAiig, 

lOOVG-AnyLAN 6/Aug. 

lOOVG-AnyLAN hub , , . , . . ;39/Aug. 

riB/5B t'tKUng stilieine ..,..,.... 27/Aug. 

7()-MH/ dcjwrhcoriverter 83. mOtl. 

H/7 riiode ... ...,.,.. ,.,71 /Apr 

A 

Abort . . , . * . v> y . - - - , . * * v-> . 65/Der. 

Abort rec^iJ^eiy G&Dec. 

Al>s1rHC'l class .... (WDi»c. 

AbslracT scner ..,»,,,.,,,.,.., bb/U^v. 

Access lurLtrol list (ACL) 4fi/Dec. 

A<?cess delay ... . WAug. 

Accuracy ijrobleni ,. 4B/Oct, 

AC:iD as/Dec. 

ACIS kernel 7/Ocl 

ACL ifar:il>a'^f> ..,.....,,,,,,.,* OOyDec. 
Acii<)jv ruuiiiics ....,.,,♦*♦,,.... 14/Oct, 

xActive tags !l4/T)tH'. 

AdaiHive tbresholti 4H/Aug. 

AggrcgJiT.es .*......-. KVDet*. 

MM tadvajiced interconnect 

tntjdelingj , , , . HT/Feb. 

Algebraic facforizatioti-s lOS/Feij. 

Alhis eiitjies 2r>/I>ec. 

Aniplifieti spoiitaiieous emission 

(A.SE).... 7. 13/Feb. 

Aniplirier lest set . , l^VFeb. 

Ai!i|jliiler, I. riri-|ini fiber-op Uc ..... 9/Feb. 
.\i 1 1 1 1 ] i n I cl e vol 1 1 pensatiott vi re u i t. ..01 /0< i . 

Analog vuk^ti , . . . 52/Aug. 

Aimlytic hltnids 26/0<'l, 

AiiJtlyiic iiurface , . . . 2JV(JcL 

Afijiiytlc surface ty|jc deiectiun , . . 6G/C3ct. 
Ant ire fleet ioti coating .... 'M, 45, GS/Feb. 

A|>ex creittion 32/(Jct. 

APIs ,,_,.._... 24. 2H. 2!l m. 4in)oc. 



Application naniespace 2M>ee. 

.At>pHcation si^rver GB/Dec. 

Approacii v^alues ............... 77/Oct, 

.Arl^il rat imt ,.,,..., 38/Apr 

.Architectural model . , . . , , . , S^Aiig. 

.\SIC design 9I/Feb.. 88, 92/Jime 

.VSIC^ DFT de.sign rules I07/.\pr 

ASIC teclinology evaluation GS/Aug, 

ATM ........ , , , . , , . . , ... . ll>^^ 

.\tnmic name 2n/Dec. 

."XUeiiuator. opticaJ ;54/Feb. 

Artnbmes ^Oct, 24. 2^1/Dec. 

Audio .......... 8/Apr. 

Audio Interfaci* 4fl/Apr. 

Auditing 47/Dec. 

Auger recombiiialion . 2JVFeb, 

Aua»t>ni:kared RPf^ , . . H, 47/Dec. 

AutbenEit aiion protocol 28, 4M}ee. 

Aulluniiiaiiejn ^, 4M>ec. 

Automatic place aud muip 92/June 

All ton tali c scaling 55/Ang. 

.Auiojtjalic HcaJt insert jim tM/Feh. 

Automat jc vehicie identificatlfiu 

(AVI) MJVDec. 

Attli:isaiTipler ...».*....»..., 14^ rJtVJune 

B 

Back porch , * . *^ . , ^ > . , . ... . . • . . 52/Aug. 

Backlight saver 51/Aug. 

Backscatter RF/ID 95/Dec. 

Bajulwidlh, luAN ...... .... . , . , , 16/Aug. 

liquid width ill locators 37/Aug. 

Oaiul width guaiantees *35/Aug, 

Bandwidth i^hiulng ....... . , *JC>/Aug. 

Base class ...,,.,.. tMl/Dec. 

Ba^' class library 5i/Ck*t. 

Ba.se develof Jtueiit emironJiient . . 6tM>ec. 

Basic local tjperation [B-LOP] 8/Oct. 

Behavioral niodeling .,...,.,... JH/Feb. 

Beliaviural simulation , ,,.... 2^VApr. 

Benchnnuk tircuits ...,., 67/Aug. 

Bezier splines ..♦»,,..,,»•..•».. t52/Oct. 
B frames .,..,......._........ 02/Apr 



Binding ..,,,...,,, 29/Dee, 

Birefringence 2S/Feb. 

BIST inH*lenientation = KB/ Apr. 

Bit processor , . r, , , * .^ 78/Feb. 

Bit slice .... 9ci/June 

Blank level .....,, 83/ Aug. 

Blend surface crealion .......... 29/nct. 

Blending 24 61/Oct. 

Block codes . . .^ w. ^Vvw,. . ..^.. . . 27/Aug. 

Block move ...... .... 44/Apr. 

Block tTai\sfer 4lVAj>r. 

Blot k write 4a/.Apr 

B-tt>P t basic local operation) ..... 6/Ocl. 

Blue hgjit 72/Feb. 

BfM>lean engine . 74/( Jet. 

Boolean factorizations 108/Feb. 

Boolean set operatioas ...... 7, 8, 74/Oct 

Bottndaty reprt^entation tB-rep) 

modeleis 7/( )ct, 

Boundeci fk*Iay , < 3^Ang 

Bmrrch flat a (irchitectiu-e , 7;3/Dec. 

B-Hep model ...,......,,., 74/C)ct. 

B-Rep (iKumdary representation) 
morlelera . 7/()t I , 

Bridging defecls 1 12/Feb. 

Bridging fan It model 1 12/Feb. 

B-^spiine 25. 02/Oct. 

B"tree clustered file 67/Di*c. 

Bubble cell , . 14, 63/June 

Bubble factor . , ,...*. t ^ *.. . . H, 6-4/June 

BubbleWorld (i^V.Iujie 

Buffer fVJune 

Bulletin boajd . . ... 59/()cu 

Burst error 30/Aug. 

Busint'fis servers , 7§/Apr. 

BtLs interface block 92/.June 

Bus sizing . 0-lUune 

t 

C ^oftlSench 82/.June 

C++ . ...,., 55/Oec. 

C++ rl:Lss lihrary .............. hlWev. 

C++ Soil Bench 8;4/June 
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CaiM types T/Aiig. 

t:ach(? (Model 71:^ ) . _ . 6/Apr. 

C^che orgajvization ( PA 7100LC) . . l&ApT. 
CAD object manager ............ 51/Oct, 

C'alibration attenualor * . . 94/C)ct. 

Calibration, op Meal receivex fi^eb. 

Call progress , , , 69. 73/Apr 

tianaJ siirfeces . . 2(V0ct. 

Caller4D (39. 72/Apr. 

Capillary - * * , . . G, 11, 25, 57/:iime 

Caplllai'y cwiliiig sysl<?m 27/. June 

Capillary electro jihoresis (VJuiie 

( 'apilbiry eiertrophoresis 

detector <'elJ ........... . , , . 62/June 

Capillary eleftrophoresis 

instrument ....,.,,. ....... HJ/,lune 

CapiUaiy gel electjophoresis . . tJ/June 

Capillaiy handling '25/Jiuie 

I'apiJtaiy temperature eontroJ * . > , 11 /June 

Capping . . . . , . ^ ... 68/Oet. 

C'aptnrf* window 95/Dec. 

Carrier lifetime OCVOct. 

Carry look ahead a<lder (iti/Apr. 

CascadcxI control 42/Jiiite 

Casca4(?d hulja , . . , 14/Aug. 

Ca^^etin ...*....,. 2l>/;jyjie 

Catch block mn>m% 

Catch Lnrornialion 15/Oft. 

CDS advertiser , 2f>/Det\ 

CDS direftoiy sliia.lur'i^ , 2(VDee. 

Cell Dir^H loo' Sf^rvlee {CD^) 23/Dec. 

f ]pll manager fifJ/Dec*. 

( ^ramic resonator U2/0ct. 

i mmvl fUters m, 9S/Oet, 

C arge-coupled device (CCDj 4G/Aug. 

Child pointers .... 26/De<r. 

CHIPTEST instruction ............ lOK/Apr. 

Chiral liiiidysis 12/June 

Chunk size ......,* . * . . . 7S/June 

Circuil doTuain 97/Feb. 

Clfiss 6(¥Der. 

Clearinghouses ................. 2(>/Dec. 

Client classes . , , . 55/nec. 

Client proxy object ............. 55/llec. 

( Ment/>ji*rvL^r inn ding , . . . 10/Dec. 

Clienty^i-rver inottel G/Der. 

Clock tree synLhesis* and 

verification &4/Feb. 

(■luster manager 51 ^ 5ti/0ct 

COBOL Soft Bench ■ B2/June 

CODEC 71/Api'. 

Cociing h) KXlVCJ-AnyLAN 27/Aug. 

Cofai-tor lOtVFeb. 

Color lookup tables » . » 49/Apr. 

Color precision 52/Apr. 

Color theoO' ^ 52/Apr. 

Command-line inteifaee (CU) 7 1 /Dec. 

Commit ..,.,.,.. 65/Dec. 

Common ACL manage merit module 

interface ....,...., , SyOec. 

Common lisp GS/Oct. 

Common Object Request Broker 

.Arch it ec t u re ( ( O RB.^ ) 86, 95/Apr. , 76/Dec. 



Coniplex interfaces 77/Feb. 

Complex signal.-^ , . . . . 87/OcL 

Composite name 'iiO/Dec. 

(Ximposite video signals 52/Aug. 

Com pound name ............... 29/Dec. 

Computer vitsion 08/June 

Concrete data class ............. tiO/Dec. 

Constant -ladius; blends 25/Oct. 

Con.stnictive .solid ge^imetry (CSG) 

modelers 7/OcT. 

t Constructors ........... .... (iO/Dec. 

Contain met 3 1 values 77/f )ct. 

t:ontext 29/Def!. 

Cantexi implementation 28/Dec. 

( oniiYjl signaling 24/.\ug. 

Ctinversation or session keys ..... 4;1/Dec. 

('oq>orate centralized data 

arehitceture 7y/I)ec. 

t lost -benefit analysis .... iWAug. 

VrV partitioning { PA THlOLt^) 1 4/Apr. 

Cnish recovery 65/Dec. 

Critical paUi testing , IGB/Feb, 

Cross (alk 19,21/Aug. 

Cjf>ss talk anal>T5is , 22/Aug, 

Crosa- tangent c-ur\"es 28/Otl. 

C'l^^ptograplac keys ............. 41/Dec. 

C:iihe lOtVFeb. 

Cube partitioning 105/Feb. 

Carrent measurements . , ........ 41/Jurie 

Cyclic redundancy ihecks . , 31/Aug. 

D 

Dnta access arrangement ..... 69, 71/Apr. 

Data ent*ryption -JJi/Dec. 

Data encryption standiml rUES) . . 43/Dec. 
Data exchange, 

IIP FE/Solidriesigner 35/Oct. 

Data stnicture maiiager ......... 51 /Oct. 

Database .server . . .... .,..,., . . . Gl/Dec. 

DC:.\JVT - 71/Dec. 

DCE cell ,7. tWDec. 

DC E :lirecioi>^ senlces 2a/Dec, 

DCE inrrfistiTictme t9/Dec. 

DCE names , - 2;5/I>ec. 

DCE najnes|>ace 13. 2:M)ec- 

DCH: I'cgLstry 3K/Dec. 

DCE RPC 8/Dec. 

DCE .secuTity service 41 /Dec. 

1K:E threads , 7/Dec. 

Deed 44/Dee. 

dpi (dots per inch) 4fVAug. 

Debug and It^t (PA 7U>(]U^J ...... 32/Apr. 

r)r hugging serial tests .... 87/Feb. 

1 ^elay fault testable circuits , . , . . ICKVFeb. 

Delay modeliitg ..._,.,,... 9ft/Feb. 

Delay ratio 1()3/Feb. 

E)elay versus wire layer ....,.,,. 102/Feh. 

Dentand priority protocol 8. 1'l/.^ug. 

Derived class WDec. 

Design n \ el h odologies 

(PA 7M10LC) 23/Apr. 

Design process (PA 71Q0LC) . 13/Apr. 



Design niles, /VSIC Dfl' U)7/Apr. 

Design mles, metaJ width 101/Feb. 

Design rules, luDQ ti'sling 33/ Apr. 

Design-for-testability features ... 107/ Apr. 

Desktop scranners 4H/Aiig. 

Destiiictoi's , , an/TJec. 

Detection, CE , , 1 J/.lune 

Detector diodes . , 04yDec. 

Detector linearity ernjr 97/C)ct 

Detects jr module KJAlune 

DPS client t omponerits WDe<.\ 

DPS .sen i^r romponents 14/Dec. 

r;PS token manageineni 14/Dec. 

Difreix'ntial group ilelay . 29/Feb. 

Differential ttuantum efficiency . . . 23/Feb, 
rUgital vifieo stjmdards .......... 6{)/Apr. 

Dimension -driven modifications . . 12/OcL 

Diode array detector 2Q/June 

Di<jdf ajTay spectrograiili ........ 11/June 

Directory information ba.se ... 24, 25/Dec. 

Directory senlce interfaces 24/t)ec. 

Directory? services ,.,,,,........ 2^3/Dec. 

DirectoOT system agent (DSA) .... 25/I^ec. 

Directory iist^i' ageni (DU.A) 25/Dec. 

Di.screte cosine transform ... fiO/Apr 

Disk luray coiil roller 71/.lnne 

Dist Jmce h^aming senuna.r ....... 38/Aug. 

Dislinguished name 25/Dec. 

Distributed computing application 

rnanagi ment { LK^AM) 71/Dec. 

Distributed Ciiinputlng Environment 

(DCE) 6/Dec. 

Distributed fde service (DPS) .... i:3/Dec. 
Distributeil time service (TJTS) , . . 12/Dec. 

Distributed system testing . 7(VDec. 

Dither 52/Apr. 

Dither table shape i5ti/Apr. 

DN:a iiiialysis 12/Jitne 

Docnineni Bcimning 4Ky.\ug. 

Dot clock regeneratioti 53/ Aug. 

Double-balanced mixer 9MJcl. 

Diiving %-alues Pi/Oct. 

DT.MF tones 73/Apr. 

DTS clerks 12/Dec. 

DTSsenei-s 12/Dec. 

DUA cai he 25/Dec!. 

Dual issue 2a/Apr- 

D ual 1 on e ami I i f retiuency 

fDTMF) .... 69/Apr. 

D>Tiamic nKideling tj, 7/()ct. 

Dynantic naige .....,.., 22/Juiie 

E 

Economir model ............... 61/Aug. 

Edge emitting LED (EELEI» WFeb. 

Edge nonmanifold . . . , 75/i^ct. 

ElSA-to-SCSl controller 7DJiii}e 

£lSAConfjg _,._,_ 7{i/.lune 

Elect rodes 2lj/.Jime 

Electrokinetic irOe4:"iion t5/Jnne 

Electronic schematic c aptvire .... SH/Jnne 
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ElectrocKmotic flow , , , . . 6/Jiine 

Electrophoresis ,.,...***,..*..,. 6/Jyjie 

Embedded clocks , . TTiTeb, 

EMC and ESO control ,,. ,.. KVApr 

EncapsQlatiori 9S/Apr. 

Ejicma9000 toolkit ^2/D^\ 

Eucina cell , . . . » , . SS'Dec. 

Etid-to-end delay * -M^Ayg. 

Enterprisi? n3mes|>ace ........... 2M>ch'. 

Entity manager , . 51, 53/OcL 

EiTli%'-sefjuenced file ,,,,... 67/I}ec. 

Ertiitmi-doped fiber amplifier 

(EDF.A) WFeb. 

Eriaium -doped fiber ampUfier 

test system . ,,....,, 13/Feb, 

Error detection .,_-.. , _ . 27/Aiig. 

Etkemet (IEEE 802.3) 6/Aug. 

Euler operators , , 2M>C't- 

Evaluating performance claims . . . CT/Aiig. 
E\'alyation .....,...*.....*.*... 43/Jime 

Ei^ent not! fl cation * , B&(Apr. 

Exception handling ...... 5S/0ct.» 6Q/Dec. 

Excejjtion model . - . - . 58/Dec. 

Exlenried li^htpatl^ capillary , , , . , 14/ June 

Extended pii\iJege attribute 

c(>rtiric"m> fEB\(;) 4'A/Do<\ 

Extended registry' attribute 

(ERA) ,42, 45/Dec. 

Exlensiati language 69/tl€t 

F 

Piiiling ii'si vectors , , ^ . , . , llO/Feb. 

Failure notification „,,,,. . - ,,.,,. 80/June 
Failure reco^f^ery ,........,.-.,,. StVJune 

Fallback security technologj^ ;j(5/I)ec. 

Faj^nd cross talk ( FEXT) 19/Aur. 

Fast text 4'1/Apr 

Fault: diagnosis IID/Feb. 

FiiUlt models ..... ...... lll/Feb. 

FDt:!l . . , ...,..,.,...,,, 10/Aug. 

Feature recognition ............. 10/Oct. 

Fe<lenited n^itning £8l/r)t*c. 

Fetal monitoring measuring 

juethotis • * , - 83/Dec, 

Fetal ti^lemetty sysfytn .......... 82/l>ec. 

Fiber test system ^ automatic ..... 57/Feb. 

Field prograniinable gate arrays 

(FPG.%) - . . . . , . , . . :JO/Apr. 

Filesets . . , ... . . ... . , . . . l^VDec. 

Filleting 2^0a. 

Filter fund ion logic, . , , , 57/Apr 

Filter pole gain 95/Oct. 

Fijigt>r iulonnallon ...,_,,,..... 35fl3ec. 

Finnware* CE 36/June 

Fixed analyser niediod 3fJ/Feb. 

Flai t>anel display . . , 51/Aug. 

Floattng-i>oint unit , . . i9h\{n. 

Flushing . 32/tlutie 

FM demodulator B2/0ct. 

FM discriininatnr ...... . . ai, d&Oii 

FM outputs . . . . , D8/()ci- 

ForwfU'd differencing fU/Apr. 



Frame buffer , 4^1/Apr, 

Frame buffer architecture 5d(Au;g. 

Fl-ame buffer control 58/Aiig. 

Fran\e formats 3(VAug. 

France rate matching 56/x\ug. 

Frame rate syTiclMX»nization ...... 59/.Ajjg. 

Framing algorithiE^ TS^eb. 

Framework cla.'sses , oS^Dec. 

Free solution capillary electraphor^ss 
[TSCE )......... mune 

Freefonn blends 26/OcL 

Freefomi surfaces .............. 6M>ct. 

Frecjuency response, optica] 

receivers , OT'eb. 

Fringing .....,,, ,,..... 100/Ft4x 

Front poix^h , , ► . 52/Ayg. 

Frontal analysis 59/Juiie 

Tj (irAn.*iitlon frequeufy) fJY/QcL 

Fused silica CE capillary ....... 6, 57/June 

Fusion nielhod . . , ffil/Apr. 

G 

GDS components ...... . -^ ..... . 25/Dec* 

Generic model, serial 

conuiumication system?i . . ... 78/Fel>. 

(ieuieric Security Service API . . 4^, 47/Dec. 

Geometry 7C/Oct, 

Geometry engine ... 61 /Oct 

Geometiy selection 10/Oct. 

Global Dii'ector>^ .Agent (GDA) .... 2^Um-. 
Global Directoiy Service^ (GDS) . . . 23/Dec. 
t.rlohaJ nan^espace .............. 23/rJec. 

(Trapltics acct^leralor 4ri/Apr 

Graphics clii}j . ■l;3/Apr. 

(iSC (general system coruieclj Ijus 
6,80/Apr. 

GHV interface S&Apr. 

Guaranteeti peifonnance .....,- ^ 15/Aug. 

if 

llalfword instructions ........... 64/Apr. 

Haidware caches ...... , , , . - * . . . Wikt 

1 1 arf I wai e descripti on 

language (MDLj . . , . , IH/Fch. 

Hiu-dwiirt^ RAID arclutectiires . - . . 7;J/June 

llL'RX-8 graphics device 52/Apr. 

Itierarciiical bit streams . , , , . 77/Feh. 

High priority — l:VAug. 

1 1 igh- vol rage control 40/June 

lligh'Q restmalors (Jl/OcL 

Hi.stoKi aiiis atid threshokls ... 48/Aug. 

lli.stoiy- based systems 7/Oct. 

HIVE H7/Fcb. 

Hot-plug . > . ... 7l/J«nt* 

HP AccuPage 43/Aug. 

IIP CE iiLstmtnerit .... K)/.lune 

HP ( hcntSi^tliuti UK 44^,Iune 

HP Color Recovery 49, .^1/Apr. 

MP distributed Sntalltalk ..... 85, 95/Apr. 

HP-PAf , 7(yApr. 

in* I'B hus * tuiverier 8()/Apr. 



KSYNC ,..-,_._ 52.'Aug. 

Hub design , . , ..»..,* . . * - * 3&^.\ug. 

Hubs .... , i;Mug. 

I 

IppQ implement^ation 3^^hl 

IDL compiler (idl-i-f ) 55^9ee. 

IEEE 802,12 ......*... a^^Aug. 

IETF ... 3«yAug. 

IFbandwii MfOcL 

IF module 82, 89/Oct, 

I-frames 6l/Apr. 

1(}ES . aa/Oct 

l'Lt)P (intelligent local operation) . . 8/Oct. 

Imaging, voltage contrast . . . I0l2/Apr. 

Impulse noise , , . . 21/Aug. 

IiHircuit entnlatlc^i SW.-^^r 

Index guided lasi?r 2()/Feb. 

hitlexed color 52/.'\pr. 

Information teclmoiogy . . ........ It5/Bec. 

Inheritance , , , . , .T77T7S7/Apr. 

li\lecitf>ii , 32/June 

Ii\icctk>n control algorithm 4L/June 

Integiated login , , )34/Dec. 

Int«^g^ratcd Ic^in library 

(Itfaauth Ubran) SS/Ttec, 

Intelligent k>cal operation (I-LOPl . . S/Qct.. 

Intensity 45/Aug. 

Inteasity noise lech nig ue ......... 6/Feb. 

Inter arriv;il-ti me jitter 35/Aug. 

Interconnect ..,,.. yT/Feli. 

hvierf^ice Definition Language 

( ll)i.J ....,; 85/.\pr., G, 55/Dec. 

Interface repositoty . ..,•..., .... 87/Apr. 

Interferrnnctric method -iO/Feb. 

Inieiiine r::tpacitiince , . . H)()/Feb, 

Internal sampling ^, .«,.,, . 34/ Apr, 

Inti>riJoIation profilers .,........,, ii'^l/Ocu 

In terpt>lation subtraction 

useliiod 13/Feb, 

lutprro^alor SWDec. 

lnterrut>t controller SO/Ajjr. 

Iut**rseclion giaph 7B/(>ct. 

hit rac oiled frames 61/Apr. 

I-Q down-CT>nvener 83, 102/t3cl. 

Isoelectric foctising .............. 6/Jime 

ls*>tachf>tJhoresis . , 6/June 

Iterative protot>iiing . , , . 99/Apr. 

ITIM naroiwbaiul ISDN ;MVAug. 

J 

Japanese HI code ...... . . 89/Dec. 

Jitter analysis 49/Feb. 

Jitter tolei-ance ... ..... . 55/Feb. 

Jitter transfer 56/Feb. 

Jones calculus 28/Feb. 

Jones matrix 27/Feb. 

JPEG I>0/Apr. 

JTAti ( IEEE I mS) . , . .•.:,.. . , . . , 42/Apn 
Junctions 2t5/D(*c. 
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K 

Kt'rbr!T>.s ,.-.,., 38, 41/Dec-. 

Key diKti-ihaitian center (KDC) . . , , -IS/Der. 
Keys 4M)ec. 

L 

LAN ineg;it'*^ll A 1/Apr. 

ULser jiajTfiwlmnd * fWFeb. 

Laser, blue , 72/Feb- 

Lasen mill H^tuiinr Hill well ridge 

WfiveguJdc* 20/Feb. 

LtLser, surf ace emitting HT/Feb. 

Laser, v;*nu"il-t'avii,y , . , . 7jl/Feh, 

LASl (LAN/St\Sl j cliip 6, :36, 8()/Apr. 

LegMcy enviroruiieril ,...-..►.... KVDet. 
Ubauth libraiy ..,.,...,,.,......, JJ^^Dec. 

Lifetime, session 36/Det". 

Linear aceumey 48/Oct 

Linear dcux Uirtinuji ........... 9f5/OcL 

Unl^ initiitiixaUiJJi .,....,,* 16/Aiig. 

Liquid eiysUd (iisplay (LCD) 51Mng. 

liquid er>'stril display terhnolo^- . :l:yAug. 

Liquid-phase analysis , S/June 

Loeal area net, work technology .... O/Aug. 

Local o]jerations 8/Oct. 

Locking ser\ice ,.,,...,,,...... 64/Dec. 

Lofting til/Oct. 

Log weighteci average .......... 104/Oct* 

Logic synihesis 9I/Keb. 

Logical channel identification .... 79/Feb. 

Logical data volumes 64/Dec* 

Lfigiii 34/Dec. 

Loghi expirations 37/Dec- 

Lt>Py . met 

M 

Maiati/^VVentzel model ........... 5l/Aiig. 

Mfmilbld so J ids 74/fk;t. 

M^wlmig ;ilgoritiim 26/OtL 

Master/slave replication , , 72/DeC- 

Match criteria 73/Apr. 

Media access control (MAC) . .. .. 1 8/ Aug. 

Media recovery . . - CJS/Dec. 

Member functions ,.,... GO/Dec:. 

Memor> font roller (PA 7 mOLC) .. ir>/Apr 

Mc^ssage dif?est 5 (MD5) algorithm 43/Dec. 

Metal migration analysis , . H4/June 

MethcKl ext^cntion 3T/*June 

Micellar elect rokinetic 

fhroniotiJ^raphy 6/June 

Microglass lathe , , , . 63/June 

Microiathe tMVJtme 

Microwave receiver 80/OcL 

Middlewiire , . 61/Dec. 

Minoring 72/Dee. 

Migrtition time reprotlucibihty . . . . 51/Jiine 

Mixed-language debugging 86/June 

Mixeddanguage model SiVJime 

Modeling resolution ............. TS/Qctn 

MocJular measuneTnent system 

tMMS) , 8t/Oct 



Movement: control .............. 40/June 

Ml'i-^tr campression ............. 6i/Apr 

MPEtj deeodir\g 65/Apr 

MPEG decompression 03/Apr, 

MPEtM fiO/Apr 

MI\>wer 2-tl .,...,. tifVAi>r 

^tgUAD... 15/Apr; 

Mullicell configurations 47/Dec^ 

Mullilevel signaling 21/Aug. 

Mul!ilevt4 !s>Ti thesis lfJ7/Feb. 

MLiltiinediaapi>lieations ......... ^3i3^Aug. 

Multimedia itiHimcdoni? .... . 21/Apn 

Multimedia wtakstation (VApr 

Multiple inteiiares ,..,,.,....... 77/Feb. 

Muhiplexinf^ ....,,,,,,,,,. 29/Aug. 

Mitltitlueailed processes tj9/Det'. 

Multi-( j nan t n f I t-well ri dge 

H'a%'eguide la^sers .... , 2()/Feb. 

N 

Name 23, 29/Dec. 

Niime-ba.sed autliorization 42/Dec. 

Maine sen ice independent ^NSI) API 
n.24/Dee. 

Namespace .23, 29/Der. 

NarnLng 88/.\pr 

Naming convention * . . . . 29/Dec% 

Naming rederaiiisn 28/Det:. 

Naming f>olicy 28/Dec, 

Naming seivice 28, 29/Dec\ 

Naming syrUax 28/Dee. 

Naming systenLS 23, 28, 29/Dec. 

Narrowband la.ser t>]/Feb. 

NdiYVOj t}3/Feb. 

Near-end cross talk (NEXT) ...... 19/Ang. 

Nested triinsaction G5/Dec, 

Net present vatue , 52/Ang- 

Nt^twork t'omputing Mt hitecture 

(KC:A) B/Dec, 

Network Computing System (NC^) . myt^c. 
Netw^oik dali] representation 

(NDR) ItVOec. 

Network interface card 41/Aug. 

Net work protocol layers . . . , 15/Aug. 

Network time protocol { NTP) .... 12/Dec, 

Network topologj' 8/Aug. 

Next-nauring-sysiejit pointer :MUpc. 

Node manager , . G9/Dec. 

Noise 22/June 

Nondeterministic bit streams 77/Feb. 

NoiTual priority ..,..,.., 137 Aug, 

MRBS (nonumforrn rational 

li-sijline) 25, eUOct. 



Object fiO/De»c. 

Object class , . . . 24/Dec, 

Object entries 2(}/Dec. 

Object identifier ........... 2G/Dec. 

Object management group 

(OMG) ....]... 85. 86/Apr., 76/Df*c. 

Object management semces 51/Ocl. 



Object-oriented applieatifm 

framework . f55/Dec. 

01 ^|ect-oriented development 

environn\ent 8ri/Apr 

Otiject-oriented progjamniing .... 7il/Dec. 
Object reque.sl broker 

[ORBJ , SS/Atir,, 7tyDec. 

Object technology 97/Apr 

(;)bjeet testing framework 

f OTFl 75. 7T/Dec. 

OCH algorithms 46/ Aug. 

OC!R engine 47/Aug, 

Offset surface 27/f k-t. 

Oitgonucleotide failure seqiiencas . . H/.lune 

(JMVPE 22, 44/Feb. 

OODBMS S7/Apr. 

f K jDCE r35/Dec. 

Ul>lical attfnuiator 34/Feb. 

Qjjtical i'-hai"acter recognition 

(OCR) 4:VAug. 

Optical GOiineotor endface 
ctiaracterization ................ lO/Feb. 

Optical isolalor 

cbaracterization 4 1 /Feb. 

Optical low-coherence 

renectometry ...... ,,..,., 43/Feb; 

Optical receiver 

characterization ,_.............. ti/f^eb. 

Ot>tica3 samp Sing rate . 45/Aug. 

tjptical system 34/ Apr.. 2()/June 

fl]>ticu] time-domain 

KenetiomctJ^^ 57/Feb, 

ORB (object request Isrokerj 

BO/Apr, 7tVDec. 

Order fulfillment 83/A|>r. 

(r>i*ganic arii! analysis 12/June 

OTDR system 57/Feb. 

0\eiTide file , 38/Dec. 

f 

Pared byte wide , , . , , . 37/Apr. 

Pat ed word wide 37/Apr 

f'acketl byte wide 37/Apr. 

Page mode , 47/Apr, 

Page segnunitation ......... 47/x\ug. 

Parallel port , 3[r/Apr. 

Parallelis^m Tl/Oct 

ParTisolid ... 7/Oct. 

PA-RISC multimedia 

instrucrtioas M/Apr. 

PA-RISC PA 71 OOLC 

prot es?H<3r ................ iSf 12, 23/Apr 

Parti<il Booleans _......... 77/Ort. 

Passive tags ..... 94/Dec, 

Piissu ords :M/Dec- 

Password st rength cheeking 

algorithms 37/nec. 

PUES Ine , . 4iV0et. 

Peak area reprodueibiJtty ........ 5 1 /June 

Peak purity measurement ........ 1;i^,Tune 

Peerto-peer conununication . (>7/Dec. 

Peptsde mapping ................ &' June 

Peri 7a'Dec. 

Pei^sonality ................. 18, 21/Oct. 
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Peisonaiity modules , , . * • . * * • , , . ^/Feb. 

Perrutl^ation , TS/Oci. 

P-franies 62/Apr 

Pboloret'eiver charat'teimtion GTeb. 

Ph>-sicaHa>w (Ptni ...*...... '^ ■ : 

PbysU-al mediuni 

dependt*iif ( PMr* ) sublayer IJi Au^ 

Phj'sifiil iiii^iini 

indi^[Ji»f*cl*?iit I PMn sublayer . . IS/Aug. 

Physical specifica£iO'iis TS^eb* 

P4-n diodes ^^Dct. 

Pin grid array 14/At>r. 

Piniivd dialog boxes !0/Oct. 

PL\ iin?thoddogy .,...„. 23/Apr 

?im:e and route ........ ^/Feb., 92/Junf 

PouK-art* sjjliere * , 27, 29/Feb. 

Poiseuiilo flaw ...,,.......,»,,,, 7/Junt' 

PularizaLian dispeision vector 2B/Feb. 

Polari^Ucin extinction in<'lbo<1 . . . 14/Feb. 
Polarization-mode 

disficrsion * *..... 27, 41/Feb. 

Policy cliain . . . ...... *^6/TJci-, 

Poiyetbyiene glycol surface 

coatings 59/Juiie 

PoljmorpJiisni , , S)7/Apr. 

Polynomial anthiuetic 31/Aijg. 

Portable Operating System Interface^ 

(PtJSLX) ..,,,.,,.. ^ . , 7/Dec. 

PosLsilicon vf»rificatic>n .... 26, 29, 31/Apr. 

PotentiaJ detection 1 15/Feb. 

ppi (pixels por inch) 45/Aug, 

PrecijBion reflectometer .......... f5S)/Feb, 

Pn^pare * . . .... 65/Dec. 

Pro^ok^ctor trt?ntft»ring . ...... 85/Df.l. 

Presentation/semantic .sf>lit . . , 88* J^7/Apr. 

Preisilitxin vcrifl cation . * 2(5, 2S/Apr. 

Pressure iJ\fecUofi ......... 15/Juue 

Pri\ssiin^ nieiisiu'enients , 4l/June 

Priinaiy Ifigjn ..*... 3iyilec. 

Pmuax-y storage ..,,..., » . , . T2/3uiw 

PrincijiaJ 42/Dec. 

Priiirijnil keys ,.,,.,....... 4.1/Dec. 

PrinkT tbroitgiiput KWOct, 

Privni*g^-ba»scd aulliori station ..... 42/Dec. 

Privilege service . , . , 45/Dec. 

PRODEX _ . 45/Ot't.. 

PnKluctdf«?jgn (Mmlel 712) .,..,. 75/Apr. 
Product design (IIP SlOmA) ..... r)7yAug. 

PrcHkicl stewm-dship ,..,.. 77/.4tir 

Program anin^atii>ri . - 85/Junc 

?rt>granunablc gain block ........ 95/OcL 

Progranunaiilc optical 

attenuator . _ _ 34/Feb. 

Pi-oSTEP , 45/nct. 

F*rolein analysis rjT/June 

Pmtocol data miit ( t^rni) lO/Dec. 

Pseudo color , . . . Tfi/Apr. 

Puisc detection _ Q&OcL 

% 

Q HWik-i. 

ijuiid flat pack fQFP) 1 1/A|.>jv 



Quanluni well ...•,..-••,..., 21, 68/Feb. 

Quaitet signaling . - . , ^ . . ^ • 30/Ang. 



Hadk> frequency identification 

iPFID) .,,. M/Dec 

RAID technology .... 71, 74/.June. 72/Dec. 

kaiiniml ,,...... ._......,. 2mM. 

liandom it^^ing 2JVApr. 

Ritpid prolotyping ♦ 29/June 

RC delay lOl/Fcb. 

Reader . . , 94/Dec. 

Read-only tags .,..,. 94,'T>(*c. 

Read/'\mie tags ,.,,,... 94/I>ec. 

ReaJ-time clock ............ ^/Apr. 

Receiver cliaraeterizaddn* 

oiJlical 6/Feb. 

Receiver, inlrrfiwave ............ 80/Ocl. 

Recovenible queueing service ... . 68/Dec. 

Rectangular area fill ............ 44/Apr. 

Refcount entitles 53/0«rt 

Reference 29/Dec. 

KefltnMion of siolids TS/(Hi. 

Rcflectometer, precision optical . . .'iWFeb. 

HcflcctoHu*! r> . i>plical 

low-coherence, ................. 4ti'>''eb. 

Regional centi'ali^ed data 

architecture . . . , ,:i , . * , . ; i ^ - , . . . 7M)cc. 

Registry * . . 37, 41/Dec. 

Relation solver 7, IWOct. 

Relatior^s ^Oct. 

Rt*la(ive distinguished name . . 25/Dec. 

Rf iative file ...... . .... 67/Dpc. 

Relative iiitensity noise (RIN) 8/Feb. 

Helaxing 25/Qct. 

Remote tiridge IJfVAug. 

Remote procedure call (RPC*) 

StVApr., S/Dec, 

Remote procedure* call fRPC) 

interfaces ,,..,, 28/Dec. 

Repeater chit* — - 10/ Aug. 

Replenishment control 41/June 

Replenishment syslein ... 14, :i4/Juiie 

Reproducibility testing 50/June 

Request wincitjw 14/Aug; 

Rc^sfilni ion . .... i . ,...,*. * vi- , . . . 4iyAug. 

RF module .... .,...,.,.... Sl/Oct. 

Ri<ige laser 2OT'eb. 

Riflge structure . . 4;VFeb. 

Ridge waveguide lajser ........... 20/Feb. 

RIX^ tank circuit Ql^Oct 

Robustly path delay fault 

testable (RE'DFfj 105/Feb. 

Rolling liall blend 25/Oct. 

Rotnulus ,....,. 7/Oct. 

Root of a namespat'e 2J5/Dt*c. 

Root hnli . , 14/Aug. 

Ri>inid-rol)in node selection ...... KVAiig, 

Rounding 24, 2M)ct. 

RPt' N8I API U, 24/Dec. 

RP( ' jirotr)c-ols \WDm\ 

RPi ■ seiTei' enlries .............. 2C/De<*, 



Sample and elei^tiiDiyte handling . . :i9^ June 

Sample injection ....,, 32/June 

Saturation arithmetic ....,.....,, 6.VApr- 
Sartn^ion logic , . iJB^Apr. 

Scaling 4i>, ^ov'Aug. 

Scanner software 4:i'Aug, 

St'Sl nM^gai'cll . = . , 41 Apr 

Second-hannQmc generation 72 Fell, 

Secondary Storage - 72.'Jm]e 

Secret key 41/Dec. 

Secure cotnmunjcation 4M>ec. 

Security 90/Apr., 34/Dee. 

Security server 4i/Dec. 

S^Hurit>' technologies 34/Dec, 

.Sejuantic/presentafion split . . . SS, Jl7/.^|ir. 

Sensitivity 22/June 

Sensitivity .gain, bubble c«*U ...... 6fV.June 

Separation control ....... .WJune 

St^parafjf ni ftivironnient ....... ^. ll/June 

Separation principle ...,.,,,.„,,.. SUune 

Sefiaration subunit 3S/Jnne 

Separation unit ,.,......,_,..... lOAlune 

Sequencer architectiu-e 7t3/Feb. 

Serial dtnlce test sequencer ...... 7(3/Feh. 

Serial test card 76/Feb. 

.Serial TesI l^tnguage ^........ 7G. 85/Feh. 

Serial test sequencer ............ 82/Feb. 

Server classes 55/Dec. 

S**rv1ce ticket ^fciT3ec, 

Servos , ..,,,..,, 3!)/June 

Sheet iriKk-L 

Short- wavelen^h laser , 72/Fel>. 

Simple average l{)4/( )r|, 

.SimjJie diilMTing , . . . ri2/.^|)r 

.Simi>le weighted average 104/( Jet. 

Sii^gle stgiHJU problem ...... .39/Dec, 

Sjngk^fiteti login .,,..., *M/l)e<', 

Singularity 2B, 32/()ct , 

Sinusoidal jitter 53/Feh, 

Skinnuig fiS/Oii 

Snndl poinl-size characters , 4tVAug. 

Snuilllidk . , . , M5, JM/Atu' 

Sjuooth operator ,.,,__.,.... lOfi/Feb. 
Soft Unks ....,_. i^fVDec. 

Sfjftware btiy-verstis-build 

decisiotvs , , . . ........ 61/Aitg. 

Sfiftware caches aM)ct. 

Soft ware RAID iuclutectures ..... 7'3/.Jntie 
Software Soiution Broker ....,.., 9S/Apr. 

S<iftware testing , , , . 75/De<!. 

Software video supt)ort , 48/Apr. 

Solid modeling design system ..... MJct. 

Source trode control 83/June 

Speciral library ................. 12/. bine 

Spectiimi analyzer 8(l/()cl. 

Spider <liagiam Sl/Apr, 

Stjin<* ......................... 27/t Jci. 

Spline , 62/( )(U 

Spline library - iA/Oci. 
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Spurioiis ri?sponses, EELED .. 44/Felx 

Standard cells 91/Feb., 92/June 

State manager , , 5B/0ct. 

St*jp gains , . . , 95/Oct. 

STEP (standard tor exi^hange 

of prod ur! nirKle! data) l:5/Oct. 

Stop rf^gister/split trmisfer ,,,.... 47yApr. 

Stray light ,,,... 22/Jiino 

StrijM? sef - ^ 77/June 

Stiick-at-faults 110/Feb. 

Structured fiie sysVeni 67/Dec. 

Subfi (iileKt . . 2iVDec. 

Superscalar execution , ► . , 20/ Apr, 

Surfjace coatings 57/June 

Surlace emitting laser .►.».. fi7/Felj, 

Surface modeling 61/Ort . 

Surface inodifirtl capillaries 5B/,Jmie 

Sweeping 68/Ocl. 

Switching .-..,. 10/Aug. 

Symbol synchroni^tiort 

algorithms : 78/Feb. 

SjTit hronously tuned filters 89/Q<'l , 

SynUu?S!!5 and muting .....-* ^^/Apn 

System administradon ..<........ 70/Dec* 

Si'stem adiuirustration manager 

(SAM) - , 71/De<, 



Tag - , , ^ . . . 94/Dee, 

"f^igentiaJ intersections 28, WOci. 

TAP/SAP controller lOH/Apr. 

Target transmission lime , . . 37/ Aug. 

Technological rloniain 97/Feb. 

Technology constani - . . i 67/Aug. 

TelenxetO' receiver - * . . 9(}/De<!. 

TelenietJ-y transmitter So/Dec. 

Telephony 9/Apr. 

Teleservices project 3S/Aug. 

Temperature control 38/June 

Test develof^ei-SJ , ..... 70/Dec. 

Test harness 75/Dec. 

Tfest manage rtieiit suljsystem 7R/Dec. 

Test system, EDFA 13/Feb, 

Test system, optica! fiber o7/Feb. 

TestCase cisss , TH/Dec. 

TestEnvironmeni 77/Dec. 

Testing complex serial bit 

streams .,..».,... 7G/Feh. 

Thread-lo-TID , , e3/Dec. 

Threads , 7/Dec. 

Three-tiered architectures r , . 62/Dec, 

Threshold ..... _,,,,,..... 45/Aug. 

Throw statement GO/Dec 



Tlckei-granting ticket (TOT) 42/Dec. 

lime-delay dis<^riminator ... 9D/0et. 

T1.B ..,. IB/Apr 

TLB [translation lookaside 

buffer) , 1^, 7fJ/Apr 

T^On - 23/Feb. 

TM-XA - (WDec. 

TOtU driver S8/Dec. 

Tbken ring (IEEE 802.5) 6/Aug. 

Tone detection 73/Apr 

Tool body 7, S/Ocl, 

Topology '1% 29, m, 7M)ct. 

Tiansaclion(s) mOvU 65/Dec. 

Tran?Hution manager , . . 63/De(\ 

TimLsaction processing 6 1 /Dec. 

IVansaclion processing nionilor . . B8/Dec. 

Umisat tional RFC a3yDec. 

Transcerver chip 41/Aug. 

Transformation algorithms ... 79/Feb. 

Tiansition curved 3l/0ct 

TransitLon frequency ffj) ........ JlY/Oct. 

TnirLStH.tndi>r 94, 95/Dec- 

Trirnnied mode . 39/Oct 

IVimmed parametric mo tie . , 40/Oct. 

Trimming ......... 28/Oct. 

Ttyptic digest analysis ....... 12/June 

lYue color 52/Apr. 

Try block ... 6(¥Dec. 

Tunable lawer sources 20/Feb. 

Two-level circuit , lOO/Feb. 

Two-phase locking (>D/Dec. 

IVo-dered archilecture .......... Gl/Dec. 

u 

Unbiased immding 64/Apr. 

l.lndo operations 59/()ct. 

Unforgeablc identities 50.T)ec, 

Universal imique identifier 

(LIUID) 9h 2(*, 4yDec. 

I'njsaced byte wide ............. t^7/Apr. 

Unpaced word wide ,....,. ^T/Apr 

Unshielded twisted pair (ITP) .... 6/Aug. 

I'ntrimmed mode . . 39/Oct, 

llpdale hanrllei^v .59/OcL 

ir|jgrading existing networks 10/Aug. 

User interface builder 32/Oct. 

t^ser interface, capillary 

electrophc:jresis . . 44/June 

User interface, 

HP P£/SoliilDesigner 14/Oct. 

titerine acti\^ty measiu-ement .... SS/Dec. 

Utility classes . 5<j/Dec. 

UVA'is absi:>rption detection llAlune 



25, 



Varactor diodes 

Variah le- h^md w idtii f 1 esign 

Viu-iable-radius blends 

VCO, 2^2Tllz ... .,, 

Vector signal iUialysis 

Vector sigiuil analyzers . . . 
Verifical ion methodf>logy . 
Vertex noimianifold ...... 

Vertex regions 

Verl ical-cavity laser 

Vct1 ical retrace 

Video standards 

^•Irtnal fimctioi\s .......,,, 

Virtual shelf 

Vision, coin|>ut.er . . 

VisUiiJWorks 

Voice mt)de operation , . . 

VolUige c cyntrast imaging 

Voltage, current, or powder control . 

Voltage mea.surement 

Voltiige sensitivity . , . . 

VTlAMs . , 4a/Apr. 5(>. 

VSYNC 

W 



93/Oet 
miOtL 
25/Oct.. 
6tWeb, 
a^/OcL 
87/OcL 
25/Apr. 
75/(M* 

72/Feh. 
52/Aug. 
rX)/Apr. 
(>0/Dec. 
93/Apr. 
GS/June 
9;yApr 
72/Apr. 
102/ Apr 
4G/June 
40/June 
9tVT)ee. 

52/Aiig. 



Wall lfJ2/Ai>r. 

Wavelength scanning method .... ;3(VFeb. 

Window^ accek^rator 43/Apr 

Wire capacitance .............. K)0/Fc^b. 

Wire geometry 9S/Feb. 

Wire k>ad models 92/Feb. 

Wireframe mode 4yOet. 

Worlqjlane set . . 64/Oct 

W(jrkstation. multimedia 6/Ai>r. 

Write- ahead logging G^i GiVDec. 

XYZ 

XBAR 69, 70/Apr. 

X.509 25/Dec. 

XDS/XOM APIs , 24/Dec. 

XFN K?\ , ■ 29/Dec. 

XFN enterprise policies 32/Dec. 

XFN protocols ^30/Dec. 

X/Open Federated Naming (XFN^) . 28/Dec. 

YCbCi^ f52/Apr 

\lG-tuned filter {YY¥) . 81/Oct. 

Zero bias diode 94/J3ec. 

Zen:i ii\iection effect ...... . . .... 52/June 

Zipping 2fi/Oct. 
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Part 3: Product Index 



COBIJLSoOBcwh ,. Jiiriv 

COmjL/C SkiftBc-m-h Jime 

COBOLtV.SoftBench ..., June 

HP AccuPage * Aug. 

IIP AccuPjigi^ 2,0 Aug. 

m* AfJvanceSr^ick imVG Hub 15 (EP J2410A ) Atrg, 

iiP AdvaiiceSiark lOTA'G SMVIP/Britlge McKlule (HP J2414Ai . Aug. 

HP ChemStation . *♦.,.,,. Jurti* 

HP Disk Army . , June 

HP Dtstributeci SmaUt^alk , Apr 

f IP EnrinaWMK) , Dec. 

UP lntt«^,4U*t] bjgin . . . , Dec. 

HP OODCE ...-....., Bee. 

HP PE/Complfnientao' .^ppllcuiion Prograni (CAP) .... Oct. 

HP PE/DDS^C Oct 

HP PE/MEHJ Oct 

HP PEA1E:30 ,........,._.,,_, , . , Oct. 

HP PE/Slu-etAtKisor Oct. 

HP P&Soli(ini>5iguer . IkL 

HP PE/SurfareStyler Oct 

HP PEAVorkMmiagpr , . . . ^ , . * , , _ . Oct 

HP Precision Enginpi^njig Systeuis , Oct 

HP Series 50TFetal TelemeU^- System (HPMiaiQA) Dec. 

HP SciTtware Solution Brokof . . Api\ 



HFTi^l^mre .,...•.>>...,.,..., .Apr- 
HP HA^KK)\'G Solectabie JSA. EISA, and 

PCI Adapters (HP J257:^A. J2S77A. and J25S^ J Aug, 

HP ltXlVG-.\iiyU^/900« (HP J2m5A.A. J25J>a\A) Aug, 

HP KWVG'AnyLAN I>e\'elopiiicnt System (HP E:>*163A> ...... Aug. 

HPSIOKJA Flat Panel Disjitay Aug. 

HP GIGOOACE: Instrument Jiine 

HP^^HK)Series908. Mia 92B,and93S Apr. 

HP miQ Board Test Family Feb. 

HP SIdCiA Optical AtEenuator ,,,... , , Feb. 

HP HimC Tunable La.ser Source ,.....- Feb, 

HP 8.t(MB Precision Refleclomeier Feb. 

HP SriOiiVB Lightwave Polarization .\nalyzer Feb. 

HP ! XII HI Series VrK) Models 712/GO and 7 Vim , _ _ Apr- 
HP 9000 Series m(\ MinMa 1^25. E35, E45, and E55 Api; 

HP TCJ^llA IF Module , Oct. 

HP 7 150 IB Jitter and Eye Diagram Aitaly^ser . . . . Feb. 

HP 71910A Wide-Ban<Kvidrh Heceiver , Oct 

HP mmn St^nt^s 2(HI EDFA Test System . _ , Feb. 

HP 81700 Series 100 Remote Fiber Test System , Feb. 

HpmAW Series ^ ectur Signal .^alj'zers Oct 

HSMS-28.^x Silicon Detector Diodes Dec. 

ServiceCuard/UX ...,,...,,.._..,..,..,,,.._.,.,.,... Dec, 
S^^itchover/lOC ,.,.,,, Dec. 



Part4: Author Index 



.AJtken. Robert V. Feb. 

.Albrecbl, .Man R .Aug. 

Armantrout Robert .1. Oct. 

Ann It, HeinZ'Peter . . , Oti, 

.'Vnioid. Bnatt K Apr, 

Bag well, Tim t. Fi*b. 

Haney. Dotsfjlas iVl Fob. 

Barkmis. Antbf>riy C. . , , , Apr. 

Bas.H^ Mick , Apr. 

IJJluerle. .Man in . .....,♦.♦»,. June 

Beck, Jobu P. .... .i Apr. 

Beck, Patricia .'\. , . , Feb. 

Bek, Fritz June 

Benson, -Fanies L Feb. 

Benzel, Jack D Apr. 

Bertseh. Fran^ ...__.., Jtme 

BbaiKUa. .Moke S , , . Aug. 

Blanf hard. Tcrrj' Apr. 

Boos, Andrt^'i-s D(*c. 

Bowel's. Dennis ;\. ...♦,*.*. Apr 

Braurj, HMvjd M, Feb. 

13rod. t'laus , . . Oct. 

Bn twn, tisfi S ........,, An;;. 

Burgoon. I »av id .\ Judo 



Burke, Kevin S Aug, 

Biired, Rolando R. Dec. 

Cain, t'hristopber B. , , ......... Feb. 

Canipbell, Mark C Dec. 

C^rmichael, Cbeiyl , . June 

t 'assidy, John J.. .Jr. Oct 

t asweO, I>eb(>ni!( L . . , . , , Dec. 

( nles. .^listair N. Aug. 

{ rouclt Sinani E.C , . , Aug. 

C'liniiingbain, David G. Axig, 

Ciircio, Jr^seph A.. Jr. .*,,*,♦., At|g* 

Derickson, Dennis J .,. , F^b. 

Denisogbt Bulent I. Apr. 

Dintej-, Raou) . . , , , Jtine 

Ditlrnajui. Monika Juiie 

Dove, Daniel J. . . . , . Aug. 

Eisinann, Sabine OtX* 

Enkerlin, (jer^rd M. Apr. 

ErnsI . Meier H. Oct. 

Fahlt>uscb. Klaus-Peter Oct. 

Fentaiule/., I.uis M Feb. 

Fiscliet Habnci ................... Feb. 

p\)!>ilei. Biadly J Aug. 

Vi inqiii I . .fuliu E. ,.....,...,,..,,, Feb. 



Freitag. Stefan ............ . . Oct, 

Fuller, km J Apr. 

f jboneiruy, Adei ....,,,,,,, , . Apr, 

(jittJer. Frederic Dec. 

f;iltlcr, Mihaela C Dec . 

(.Ton.lon. Gaf> B, ......... . June 

ciriidumi, Jolin R. , . . .^ng. 

(riipia. PankJM Dec. 

Halm. Kennedi H. Feb. 

Halperin. Daniel L .. ..^ ,. , , , Apr 

Hanson, Del Aug. 

Hausmaim, Jiii^en W. . , ■ ■ * * ■ D*'t^ 

Heffner, Brian L Feb. 

lienry. Steven G , , , Aug. 

Hems<'hel. Cbristian Feb. 

Hejialay, Paul R Feb. 

Higaki, Wesley li Ang. 

Hinds. David K Dec. 

Hodge. David J. Aug. 

HoUoway* Robert R June 

Hf jpkin.s. Anne r, Dec. 

Hcaowily., SaiTJTtel U. .......... Dec. 

I ioung, Yu-\1in D. Feb. 

Hii^, ncrllKiUl Oct 
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Ishak, Waguih Feb. 

Jagger^ Michelle Eioughtoa .,*.*„,. Dec. 

Jedwah, Jonatl^aii .,,...... Aug. 

Jegle, UMke .... . . , iuiK* 

JosephsoTV. D. Douglas Apr 

Jungemiaii, Roger ..,,..,.,.,..... Feb. 

Kallenbadi, Patrick . . Juite 

Kii|ji:^fiuuikis. Ai^a V. , , , T)ec, 

KeHeit, Forrest G. . ..... Feb. 

Keremitsis, Eile<?n _,_,_..,,_., Apr. 

Kiiiaii, Jens ..,.,,.,...,., Oct 

Klemni. Wolfgang ................. Oct. 

Kiiebel, Panic k Apr. 

KonininLsch, Steven J Aug. 

Kong. Mk'liael M. ... * * **..... Dec. 

Kuhlln, Miix R, _...... Oct. 

Kilhl, Markus ...... Ort. 

Kumar. Navaneet Dec. 

[^mi. Williajn K. Feb. 

Uitub, .kjel Apr. 

LtK1n*niinant, Greg D. . * . . * Feb, 

l^eckel. Eclgaj^ ...,,.... Feb* 

Lee, Ruby B Apr. 

]A'\limg. Frank J . ... Apr. 

Leviiif David 8 , . . Def. 

Ue, Hetiry RW. * Aug, 

Lloyd, Paul Dec. 

Ludowisf , Michael J ..,,.,.,. Feb. 

Luo, Michael Z Dec. 

Madden, Christopher J. , , Feb. 

Maiei, Frajik A. Feb. 

Maldonado Luis M ,.....,.,,,. Dec. 

Marcus. .lane B. Dec. 

Mars, Danny E, Feb. 

Man in, EUisabetJi A. .......,.,..*.. Dec. 

Martin. Paid Apr. 

Martinez, Antojik> A. ,....,...,.,., Aug. 
Martina, Henri^itit' A.S * . * . . June 



Maute, Alfred ... June 

Ma.\well. Peler C. Feb. 

McAIhster, C iinis R ,. - Apr. 

McAuliffe. Robert E , . . , F«?b. 

Mcl.i(iiti»al, lay D. Feb. 

McF;uUuid. Stephen J ..,,.., Dec*. 

McQuate, David J, . . . . Feb. 

Methley, Sieven G Aug. 

Melzger, Michael Oct. 

Millc*r, Christojjher M. , . . . . . Feb. 

Miller, David J. ...,.,...., Dec. 

Mimer. Rolf , Feb. 

Murillo, Karen L Apr. 

Nakagawa, Shigeru ..,,,..,,,.._. Feb. 

Noe, Terrene e R, Oct. 

f ijjit/., Kan^ten , OcL 

flrtb, JoM*ph F. . * Apr. 

Paret. Gunrer W. Dec. 

Peai^on, Roger A. ,,..,,..,....... Ai>r, 

Perez, WMam H. Feb. 

Prokop, George . . ; . . . . . . . , . - . . . * . Aug. 

Quint, Da\'id W. .................. . Apr, 

R^ue. Praisad . . . . , Feb, 

Ranganaih. Tii"UJiiala R. . . . Feb. 

Rehder, Wulf Apr. 

Ricchetti, Mkitael ...... ...... Apr. 

Riccio, Anthony L Apr 

Rice. Thomas A. . . . , . . . . ( K-t, 

Ritzmann, .\lwin ,..........,.,.,.. June 

Robrish, Peter R. ... Feb. 

Roesuer. .\rlen L .,,..,.... , . Apr. 

Rose, l^iwienf I' J. ................ Dec, 

Koser. Thomas D. ,,.,,,.,.,,...... Oct. 

Rlick. riements Feb. 

Rue^s, Hermann J Oct. 

Rusnack. Michael R June 

Ryan, Robert E. . . . . ..... . . — , . . . Jime 



Sang, jQrgen ..♦*.*.,,., Feb, 

Schild, PeterJ. OcL 

.Sf hniidt, Siegmar ....... . * . . . . Feb. 

Scbnefder, Werner , .Intie 

Searby Toii\ .1. ................... Aug. 

Seegen Marald , . . , , F*>b, 

Severaon, Ketinedi E. ............. .'\pr 

Skeie. Torn A. June 

Sloan, Susan R , , . Feb. 

Sorin. Wayne V. , , , . Feb. 

South worth. J. Scott ........... Dec, 

Sftenccr, Tlinnias V. , , . , J^pr. 

a - 
Spratt. Michael P. . Auj?. 

Stewart, Christopher E. Oct. 

Strohnieier, Fred June 

Swedberg. Sally .A, June 

Tan. Michael R.T. ................. Feb, 

Telia, Richard P June 

'Dialer. Patricia A. , , , . Aug. 

'lYott, Gai>" R Feb. 

TnionK, Da\itl Dec. 

Trutiia, Jn. Williaui R Feb. 

Tucker, S. Paul ,...__..., Ai>r. 

Van'fYiyl^ Ror>' L .....,...,,....,.. Fell. 

Walker, William L Apr. 

Wal2. Gerhard J f >ct. 

W^mg, SMi-Yuan Feb. 

WatscHi. Gregory C.A. Aug, 

Webb, StevcTi L Aug. 

Weber, Leonard M. Oct. 

Weir. Dmican Apr. 

Wii*Liero(Ier, Herben June 

Witt. Klau.s ......,, ......... .... . . June 

Yianada, Norihide .,.,,.,,,,....,.. Feb. 

Young, William E. . . , . , , Feb. 

You.^cfi, Manny .,,•....*..... Apr. 

Zimmemianji, Harts-Peti^r ...... June 
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